Orasis Software Discussion Forums -

UI controls - persist data from user to database - Newbie question

2010-07-30T22:58:29-05:00

http://www.p90xkicks.com/

we offer cheap and high quality p90x workout dvd
about p90x
p90x
how does p90x work?
Insanity Workout
BeachBody
chaLAN Extreme
Brazil Butt lift Workouts
Rev Abs Workout
Core Rhythms 4 DVD Dance Exercis
Pump it up 5 DVD
ZUMBA workout 4 DVD
Cartoon DVD
Education series
DVD movie and TV serial
Such a trend welcome to buy thank you!
http://www.p90xkicks.com/

UI controls - persist data from user to database - Newbie question

2010-07-30T22:58:16-05:00

Exercise can make people healthy P90X, the use of sports equipment and watch sports training DVD allows you to make better fitness program. Cheap P90X can you do that. Here are the most comprehensive fitness DVD and various sports equipment. P90X DVD is your best choice.

UI controls - persist data from user to database - Newbie question

2010-07-30T22:58:07-05:00

we offer cheap and high quality Vibram FiveFingers.

http://www.so-sports.com
Nike Shox R4
Nike Air Jordan
Nike Air Max 90
Nike Air Structure Triax 91
Nike Air Max 95
Nike Air Max 2003 Mens
Nike Air Max 2009
Nike Air Classic BW
Vibram FiveFingers KSO
Vibram FiveFingers SPRINT
Vibram FiveFingers SPRINT Women
Vibram FiveFingers CLASSIC
Vibram FiveFingers FLOW Men
Vibram FiveFingers 2010 New
http://www.so-sports.com

I want to combine FirstName and LastName into FullName for my mapping output

2010-07-28T20:57:51-05:00

I want to combine FirstName and LastName into FullName for my mapping output

2010-07-28T20:57:24-05:00

I want to combine FirstName and LastName into FullName for my mapping output

2010-07-28T20:57:10-05:00

we offer cheap and high quality Vibram FiveFingers.They are all new..People are finally beginning to come around to that inconvenient truth about our feet, that dirty little secret that shoe companies would prefer to keep under wraps: barefoot is better.When you wear Vibram shoes,you will feel you are barefoot.

There has been media coverage of the barefoot trend in the past, mostly intermittent, in running magazines and always taking a patronizing tone.Vibram FiveFingers Sprint follows the same formula: more idle speculation on a bizarre fad that a select few crazies are promoting, with plenty of “balance” from stuffy foot specialists expressing doubt that the inherently fragile, gentle human foot could ever withstand the rigors of walking unshod without “serious injury,” than any serious consideration of the merits. But now we’ve got a nice,cheap Vibram juicy study to hang our hats (or our shoes) on, and media outlets are falling over themselves to get the scoop.

Write by: Vibram FiveFingers

I want to combine FirstName and LastName into FullName for my mapping output

2009-04-11T21:11:54-05:00

Yes, the designer is helpful for a lot of other things, specially creating joins, aggregations, group bys, sorting, nested queries, unions. It does not handle calling functions, concatenations and formatting. That has to be done manually in the SQL.

I want to combine FirstName and LastName into FullName for my mapping output

2009-04-11T21:07:07-05:00

yeah, i did that but my question was "Could it be done in the designer?" so I guess it can't. No problem! thanks

I want to combine FirstName and LastName into FullName for my mapping output

2009-04-11T21:04:56-05:00

You could concatenate the two strings and combine them into one column in your SQL.

Eg: Select (Person.Contact.FirstName + ' ' + Person.Contact.LastName) As FullName

Your generated object would then have a FullName property mapped to it.

I want to combine FirstName and LastName into FullName for my mapping output

2009-04-11T14:05:02-05:00

is there a way in the designer to combine the database fields FirstName and LastName into FullName for my mapping or class?

Thanks.

Sql Server 2000 Connection failed when filling Database Browser

2009-03-30T21:23:37-05:00

Update release 2.1 on on 3/29/09 has resolved this issue.

UI controls - persist data from user to database - Newbie question

2009-03-26T14:42:38-05:00

Thanks for your question.

The Orasis Mapping Studio supports Lists of any type of object, whether it is generated from the Studio or is a custom type for reading and persistence.

You can wire the objects for display to a grid for example by setting the DataSource property of any bindable grid to the List of the objects that get returned from a Mapping Method:

For reading :

           IList objectList = dalClass.GetDataForRead(param1);
           this.dataGridView1.DataSource = objectList ;

Once the user edits those objects in the grid they can be passed back to the generated DAL layer method (eg. UpdateObjects) for pesistence using the following code:

        int rowsUpdated = dalClass.UpdateObjects(objectList );

UI controls - persist data from user to database - Newbie question

2009-03-26T01:45:56-05:00

Orasis Mapping studio appears to build classes that handle database queries and persistance.
How does one wire up these classes to UI controls such as Grids where Users can delete, update and insert data rows.

What is the best way of passing data to visible controls and then persisting changes made back to the database.

Sql Server 2000 Connection failed when filling Database Browser

2009-03-25T15:55:52-05:00

Thank you for your query regarding the Sql Server 2000 connection issue.

Also, thank you for pointing out that the query is SqlServer 2005 or higher specific. That will help us narrow down the issue.

Unchecking the user and system procedures, only removes them from the view. The application still retrieves all the metadata it needs at connection time.

We are working to resolve the issue. Please check back with us shortly for a resolution.

Sql Server 2000 Connection failed when filling Database Browser

2009-03-25T08:59:58-05:00

Hi all. Are you aware of an apparent issue with the Database Browser window? When I set up a connection to Sql Server 2000 and then try to connect to it I receive the following error in the Output window...

--------------------
Connection failed: 'SCHEMA_NAME' is not a recognized function name.

Query:
SELECT SCHEMA_NAME(udf.schema_id) AS PROCEDURE_SCHEMA, udf.name AS PROCEDURE_NAME, CASE udf.is_ms_shipped WHEN 0 THEN N'PROCEDURE' WHEN 1 THEN N'SYSTEM PROCEDURE' END AS PROCEDURE_TYPE FROM sys.all_objects AS udf where udf.Type = 'P'ORDER BY PROCEDURE_SCHEMA, PROCEDURE_NAME
-------------------

This query is particular to stored procedures and appears to be suited toward SqlServer 2005 (or higher) I'm guessing that the other object type queries are correctly versioned, but this one seems to not be.

Also, I'm a little puzzled that it is trying to retrieved the procedures even when I have both user and system procedures UNchecked in the browser properties form.

Any thoughts on how to rectify this? I need to test this on Sql2000 and would very much like to use the browser rather than fat fingering in the table names in the Query Designer.

Thanks!

64 Bit

2009-03-08T13:30:20-05:00

Yes, the Orasis Mapping Studio now supports 64 bit Operating Systems.

64 Bit

2009-02-27T20:15:33-06:00

Does Mapping Studio support 64 bit OS?

(ROI) on database access layer technology architectural decisions.

2008-08-11T14:16:53-05:00

In concept, estimating the return on investment (ROI) of a technology initiative is like any other capital budgeting process. The objective is to estimate the cash flows/savings likely to be generated by the technology initiative and determine whether these cash flows exceed the costs of designing, building and operating the systems and processes associated with the initiative.

The practical challenges of putting this concept into practice are considerable. It is generally difficult to quantify the benefits of technology initiatives. Often it is more fruitful to estimate the cost savings of technology initiatives by applying activity-based costing, a procedure that assigns costs to activities based on the amount of time they consume. Our real life experiences in enterprise project engagements with big clients pursuing the development of database intensive applications gave us a better understanding how to quantify ROI on database access technology decisions. It is the only way to figure out the real costs by being present on the development floor and experience development with these technologies and observe the time that is takes to develop/change/tune database transactions.

In many systems today the decision to choose a database access layer is critical to the total budget that is allocated for the entire system. During requirements gathering and use case analysis, the business data that is involved and their relationships define the actual database transactions that the code needs to execute. A technology that targets these data requirements in a direct way (Custom auto generate data services for the database transactions that you need) makes a lot of sense right from the beginning. Other technologies simply offer a black box framework that can be used as your database tier by implying that:

1. You do not worry about how efficiently SQL is build by the framework.

2. That defines multiple entities that may or may not be used with a wishful thinking that it is adequate to fulfill all requirements.

3. That the power of SQL can be fully utilized by some Object Query language.

There are many articles that people publish on the web about this type of technology choice. Unfortunately these people do not come from the actual field that forces them to use the technologies that they support in many different scenarios with steep performance requirements. A current example is LINQ to SQL where clearly it was pushed as the technology of choice to build data tiers (only is SQL server) and today it is replaced by another framework that is pushed by the same company.

Choosing the right database access technology the cost can be significantly lowered if:

1. The amount of coding is reduced.

2. Database access tuning is an easy task to perform.

3. The design of a database access tier is forced to be isolated from the business logic tier and directly
targets actual business requirements.

4. Performance analysis can be easily performed from one place in one tool at any transaction level without writing any code for both the raw database server response as well as the actual code that executes the SQL.

5. The technology of choice guarantees the fastest performance possible because of the code that it generates.

6. Multiple skill sets can come into one application tool to solve data issues and redundant operations.

7. Maintainability is a breeze.

There are some basic and true facts in a typical project that can explain how development costs go on a rise:

A. Not collaboration of different roles: The business analyst knows the business rules and the database analyst knows how to retrieve the data that relate to the business rules in the most efficient manner. In most cases resources that execute both of these roles are not responsible for writing the database tier. The lack of a software tool that allows collaboration will slow down development and tuning of the database tier and therefore yield higher costs.

B. ORM one to one table to class/mapping limitations: In the majority of cases the physical database schema table structures do not resemble the business model objects that are involved in these transactions and realistically they shouldn’t either. When the chosen technology relies on a one to one table to class mapping, the amount of code generated and the code that needs to be written is significantly more.

C. Framework bindings/data objects dependencies /Reflection: Physical storage should be independent of the business model objects that are used in the database transactions. Business rules can involve data from multiple tables using all different sorts of relationships. Unfortunately, many database access layer technologies either assume one to one match of business model objects to database tables or they map to multiple tables using XML files that they always have to keep in sink somehow. These mappings become very tight with the framework and the model objects (Entities) become part of the framework.

D. Object Query languages limitations/learning curve, Object cache required: These technologies use object query languages to read and persist the objects and they require object caches to perform fast. Since they are one solution fits all, they have to utilize reflection to populate data in their entity models. In some of these frameworks most of the queries performed in the systems that use them are anonymous queries that the results come back in strong typed result sets. These result sets are traversed to build other objects that represent the actual business model objects in result sets. In other cases the table mapped object graphs returned have to be transformed into different objects that the business layer understands. In both cases we end up with a lot more code, slower performance and high cost in maintenance. Object queries are not easy to write and the skill set is not popular either. The cost for pursuing a solution with typical ORM solutions is huge. Developers spend enormous amount of time building object queries and transforming the results into other object structures as well as trying to enhance performance by applying a lot of guess work to enhance the underlying SQL that they have no direct access to. In an enterprise system object caches add tremendous cost on the budget in terms of maintenance, monitoring and actual licensing fees. Some ORM technologies cannot be used with enterprise caches either since they have their own in the CLR.

E. Ignoring the power of SQL and pure ADO.Net: The power of SQL and the ability to manage it in all database transactions that make up the system by auto generating the related object code in one IDE saves time and money. It is more accurate, faster and uses only business model objects that are derived by the business data requirements. By sharing open XML format project files, that do not define anything for runtime deployment rather XML files that contain project design data, developers of different skills can focus on the database tier and enhance performance as well as fix data related issues with the ability to view real data from method executions within the IDE itself.

To reduce ROI and use a technology that has been proven to do exactly that, consider the fact that the auto generated on demand data services code is written by the IDE that promises to:

A. Greatly reduce development time – developers spend less time coding and bug fixing. Remove the complexity of ADO.Net and SQL from developers by not having to write it.

B. No expensive runtime licenses. No licenses at all.

C. Generate efficient, clean code that would cost a lot of cash to build by hand. Generates the entire DAL as source code - no proprietary run-time components.

D. No technology lock in. Orasis Mapping Studio 2009 generates source code – there are no proprietary components.

E. Guarantee code uniformity across the boundaries of the database tier.

F. Target raw performance.

G. Allow switching to different .Net languages with a click of a button and therefore utilize different skill sets and therefore no need to hire extra resources.

H. Allow switching to different databases and different middleware Providers.

I. Save money by not having to spend hours for writing Unit test code.

J. Secure deployment surprises by knowing data tier speed while in development.

To utilize a mapping concept through a graphical user interface, backed by an auto code generation engine targets requirements to their root. Build only what you need, when you need it and share it with the rest. If somebody can improve performance, simply utilize the tool, update your queries, time your results and save.
The choice of a database access technology becomes crucial to the overall budget. With the growth of the business data requirements as the majority of use cases go through analysis, it becomes evident that the table object generated graphs do not match the business data requirements and therefore more transformation code needs to be written; In many cases the power of SQL cannot be utilized at all and a lot of database processing ends up in business layer code. Porting to another similar ORM technology is also wishful thinking. The data access code is mixed with the business code and the maintenance/debugging becomes very expensive. Using Orasis Mapping Studio 2009, an organization can bring down the cost on the data tier significantly and target production deadlines in realistic time constraints.

Orasis Mapping Studio - A Beginners Guide

2008-07-29T10:23:23-05:00

What is the Orasis Mapping Studio?

Orasis Mapping Studio is a comprehensive Object to Database Mapping Tool that builds your Data Access code from the ground up. It is an IDE and a Code Generator that allows you to build your mapping layer between custom .Net Objects and existing Relational Database through SQL queries. The Orasis Mapping Studio (OMS) is the only IDE of its kind that allows users to build their mapping layer from the ground up to their requirements with no overhead, excessive languages, frameworks and libraries involved. It's in IDE that not only lets developers build their data access layer, but also allows DBAs and Data Architects to be part of the development process.

What is a Mapping?

A mapping an association of data between relational Data and Objects. It is made up of three parts; a SQL Query, a .NET Object Model and a set of Field Mappings that associate the columns from the query to the .NET Object Model's properties. Once a mapping has been completed, the OMS stores the mapping and generates a method that translates the mapping into .NET code instructions that execute the mapping and return the results.

Mappings can be either for reading Objects, where data is read from the relational database into .NET objects or for persisting Objects where data from .NET Objects is stored in a database. A read mapping consists only of a SELECT query while the persist mapping maybe of an INSERT, UPDATE or DELETE statement.

What is a Mapping Layer?

A mapping layer is a class or set of classes that contain data access and mapping methods. The OMS builds the mapping layer by building an Assembly out of all the mapping methods and classes and compiling it into a single, simple to use DLL that can be called by any .NET code. It has all the methods, comments, that the user created when building his or her mappings. The mapping layer has a place to set the connection string if the user decides to use a different connection string. The mapping layer classes are built using the DB provider of the user's choice and are compiled within the IDE for SQL and .NET errors. The mapping layer can be built using either C# or VB.net as language providers.

What is a Mapping Project?

A mapping project consists of all the mappings, mapping classes, Assembly reference and database settings that are needed to build and maintain a mapping layer. It is stored in XML format and can be easily read and distrbuted amoing project team members for collaboration.

What does the Code Generator Generate?

The OMS has a sophisticated code generation engine to translate all the mapping layer, mapping and database information to generate efficient, clean, easy to use, and human readable .NET code to build a data access layer. The code is gauranteed to compile with no syntactical errors and is written in partial classes for extensibility. The code has comments that are associated with the mapping methods, classes and assemblies for a developer to be able to use the Assembly as a fully documented data API. The code generator uses basic ADO.NET constructs and Database Provider information to generate code for performing all the database access activities necessary.

What is the Unit Tester?

The OMS provides an easy to use Unit tester, that allows users to test their mappings in the generated code. This allows the users to unit test their mappings and the generated code for performance, data accuracy and execution. This is a must have for any software developer to be able to unit test his or her own code before using it in the application.

Does OMS help developers build their SQL?

The team at OMS understand that writing SQL Queries is not an easy task for most developers. To ease the pain, OMS has a powerful SQL designer that allows user to build sophisticated queries with INNER, OUTER JOINS, UNIONS, nested queries and WITH clauses with an easy to use drag and drop graphical query builder and powerful Intellisense enabled SQL editor. Building queries with the OMS is truly a breeze.

My .NET objects are complex with inheritance, nested objects, and other Object Oriented constructs. Does the OMS handle them?

The OMS was developed with the most advanced Object Oriented developers in mind. It allows mapping of data into nested object graphs. It also allows users to select their Objects from any .NET assembly. It checks of constructor availability and only allows mapping to Public, writeable properties where rules of OOP are not violated. The most powerful feature of the OMS Type mapper is that it allows users to instantiate properties of Interface or Abstract types with concrete instances to map to, all with easy to use GUI commands.

Do the Objects that are used for mappings have to follow certain constructs, i.e. attributes, base class, interfaces, etc.?

No, not at all. The OMS is flexible enough to allow users to map into any Plain Old CLR Object (POCO) or even an Object that has base classes, interfaces, etc. as long as it has a default constructor and Public Properties of primitive .NET types such as string, int, float, datetime, etc. The Object does not have to be decorated with any Attributes, or derive from any base classes or implement any Interfaces.

Does the Mapping layer have transactions?

No. The mapping layer has methods that perform low level database access. It is the job of the calling code to wrap the method calls in Transactions using the TransactionScope class of .NET. Any mappng methods called within a single Transaction scope. See
http://msdn.microsoft.com/en-us/library/system.transactions.transactionscope.aspx for further details on Transaction scopes.

Does the Mapping layer have any caching?

No. The mapping layer is returns fresh data from the database every time a mapping method is called. Any object level caching can be done by the caller if required.

What Databases are supported?

The OMS currently supports Microsoft SQL Server 2000 and up, Oracle, MySql and Mircosoft Access. We are constantly adding new databases support so please send us your database requirement that we may add it our list.

Why Code Generation for custom data layer automation?

2008-07-25T20:50:20-05:00

By utilizing RDBMS metadata, one approach that most ORM layers utilize is introspection to generate the model objects as one to one mapping to the RDBMS tables and through the foreign key table relationships they create the class relationships on the fly. In this approach the classes are auto generated and can reside in only one code file. The ORM implementation engine is responsible to translate the object to query expressions to SQL, fetch or update the RDBMS and utilize reflection to populate the objects if necessary. Another approach is to let you define your “Entities” that can apply to multiple tables, which is good, but they control your data model objects, populate them with RDBMS data using introspection and require object caches not only to perform fast but also distributed caches to function correctly in an enterprise system. In addition deep knowledge of some object query language can get data that has challenging retrieval requirements.

While this approach sounds valid and may suffice in straight forward situations, the data access layer code is entirely dependent on the ORM implementation which is treated as a black box. The data access layer relies on the ORM and hopes that no tuning of the underlying SQL is necessary, hopes that reflection cost under huge loads will perform and in addition to that it may not even use most of the model classes that were generated by the ORM tool. Another issue is that through the object to query language, is how sufficient and easy it is to tackle challenging queries with outer joins and similar SQL contracts that a DBA should be able to produce on a timely manner. Considering that business requirements may drive the need for columns coming from different tables , a requirement that is true most of the time, most ORMs may treat that as an Anonymous type ( which is not a true model object anymore ) or even allow direct access to the RDBMS with raw SQL and return back result sets. If the initial model creation was sufficient why do ORMS support both ways of fetching data? Why most of the interactions with the ORM use Anonymous classes as the business requirements mandate better performance? The case is obvious that your model objects are defined by your business requirements and not the underlying table structure and therefore your object models should not match the persistence storage but the business logic.

With the ability to auto generate pure ADO.Net source code with no third party library dependencies, and considering the fact that a database transaction in the object world involves some classes and some tables in the database, the concept of the custom mapping becomes very attractive. What was really missing was software that allows the easy binding of the two. A mapping is simply made up of two units and has two flavors. It can originate from Objects to RDBMS or vice versa. The ability to map data columns to object fields in a bidirectional way and auto generating fast and non-proprietary code using an IDE that only focuses on that, Orasis Mapping Studio gives control to the engineers to craft their own custom data services with zero compromises in performance. The Code generation engine advices the mappings and generates efficient code. The data layer now becomes visible and not a black box. The partial classes that are generated with the methods that correspond to the Mappings define your custom API to your data; your custom automated data services layer. The IDE treats the Mapping as a compiled unit in a class and validates both your SQL syntax as well as your code syntax. With powerful visual editors that focus on mapping units, the Code generation can run every time you perform changes to your mappings. Since ADO.Net and SQL are complicated to deal with, repetitive and tedious, the Orasis Mapping Studio takes all that away from you and allows you to build data services that target only your business requirements. You will generate data services that you can fully put to the test in the IDE itself and mappings that can be looked at by both developers and DBAs. A one place stop to tune your database access layer without any black box magic.

What is the philosophy/features of Orasis Mapping Studio 2009?

2008-07-24T20:19:41-05:00

What are the features and product philosophy behind Orasis Mapping Studio 2009 (OMS)? What is the problem that Orasis Software is solving in the industry today?

The problem that OMS solves is a problem that is attempted to be solved by multiple different technologies that use their own approaches and methodologies. In the .Net world the relational persistence layer of a DBMS that is truly native to SQL is implemented by middleware (Providers) that is accessed through ADO.Net, the persistence API that uses native SQL to execute CRUD operations. ADO.Net has the reputation of being complicated with repetitive code, easy to make mistakes and in addition to that it uses SQL that shares the same bad reputation in the object programming world. Despite all of these though, ADO.Net is the standard API that the middleware providers implement and it is the fastest access to the RDBMS. There are several ORM technologies out there that have been introduced with the promise to treat the database as an object system that can be accessed through some object query language that translates to SQL. These technologies generate dynamically SQL underneath and populate your objects by translating the object query statement. While this approach has not been tested and applied heavily in the industry, it is very obvious that there are multiple questions that engineering teams should ask.

1. Is this the most efficient way to access the data?
2. How about performance under load?
3. How about the learning curve to this object query language and the expertise available?
4. Is it easy and flexible to write complex queries in this object to SQL language?
5. Can anything substitute the raw power of SQL?
6. How do you tune the database access layer since the SQL is always auto generated? As an example in a LINQ query tuning isn't really possible. This isn't really a problem related to LINQ to SQL but it's a problem related to LINQ , you need to know, in detail, how a given construct is converted into SQL: Will this result in a join, in a derived table, in a sub query in the where clause targeting a list of constants, or something else? This is especially bad because the DBA can't assist the developer how to make the query faster, as is the case with more lower-level query API’s found in many ORMs.
7. Does the ORM fit the enterprise scenario? For example, LINQ to SQL is designed for a two tier scenario. LINQ to SQL does not fit naturally with multi tier architecture.
8. Do we need an entire object domain layer or should we look at our business requirements first and generate only what we need?
9. Some designers force you to have all entities on one canvas, and generate the code into one code file. Working with 300 entities or so may be difficult?
10. Should we able to automatically test every interaction with the database and quantify it if we could?

We at Orasis Software, have asked ourselves all of these questions, put multiple technologies into the test, including LINQ SQL , NHibernate and others and came up with an approach that:

1. Satisfies ease of development.
2. Reduces development effort.
3. Is architecturally concrete.
4. Has no third party dependency.
5. Easy to maintain.
6. Exploits the best patterns and solutions that database access technologies and languages have to offer in one round trip engineering IDE that only focuses on data tier building.
7. Allows testing of every aspect of the data tier without writing a line of code.
8. Allows true N level graphical mapping between SQL results columns and parameters and object graphs.

The philosophy of Orasis Software is to harness the power of pure SQL in conjunction with Objects and allow on demand auto generation of the data access tier based on requirements with the involvement of both DBAs and programmers using a Mapping IDE with a Data Access Tier Code Generator. By providing:

1. A state of the art query builder that assists into generating queries.
2. A type selector that allows navigating DLLs and choosing data types as your model domain object graphs.
3. An innovative mapping control that maps database fields to class hierarchies by allowing expansion and replacement of contained interfaces and abstract classes into concrete types, replacement of contained types to their sub classes with type checking and auto conversion from source to destination.
4. A code generation engine that builds the data tier code on the fly with no third party dependent code in partial classes that you can expand to your own needs.
5. Exporting the open format XML project file into your Visual Studio .sln format so you can further expand it in Microsoft Visual Studio.
6. A testing capability of each method in the custom data tier with SQL timings as well as object timings by loading the auto generated libraries and testing them.

OMS introduces the option to hand craft your own data access layer that suits your needs and satisfies all of your persistence requirements.

Choosing a technology for your data access tier

2008-07-23T22:26:48-05:00

Should you choose an ORM implementation or simply allow a tool to craft your data services to your actual and immediate needs? Do you need both options in your projects? Can an ORM implementation satisfy the performance requirements, the ease of use and ease of changes? Can you really avoid SQL at no cost? Does an object query language make our lives easier or harder? Does any ORM implementation address the Object-Relational Impedance Mismatch?

Choosing a technology for your database access layer seems to be a challenging decision for many projects today. There are many advocates of different ORM implementations and object query languages of some sort. Some claim one object query language is simpler than the other; some ORM implementations support all the major object query languages and some developers write their own abstraction layer to the object query language of the specific ORM implementation that they have chosen.

To really benchmark an ORM implementation is extremely challenging since different schemas carry their own complexities and application requirements. In terms of tuning the queries, the choices appear to be quite limited with ORM implementations and require “expert knowledge” to do it right if it can be done at all.
Multiple times, the compromise of multiple fetches to generate in memory domain structures from multiple domain objects deprecates performance but at least it gets the data. In reality there is no one seemingly easy way to judge performance.

We can compare an ORM’s performance against the equivalent SQL and may turn out that this test can be misleading. Some important performance optimizations (for example, the transaction-level cache) can actually reduce performance for the kind of very trivial benchmarks that people typically write. This is more a problem of the triviality of the benchmarks than anything else. Problems that affect ORM performance in nontrivial use cases may not even exist. The biggest problems really come from what we call the "problem of graph navigation", where the pattern of data access used by an object-oriented application is a fundamentally inefficient way to access relational data. A lot of times the data required are not a one to one mapping of domain objects to tables; multiple columns from different tables can make up a model object. In that case an ORM implementation is relatively useless.
How about if we have an integrated development studio that allows us to build our own data services layer, that would allow us to edit/modify/benchmark all of our database access layer in one place with no ORM engine code underneath but only clean vendor-independent code with a choice of different drivers? If a hand crafted auto code generated data services solution is available then this is something that can be considered?

Sometimes the problem is sort of cultural. Some developers come to using ORMs because they are uncomfortable with SQL and relational databases. ORM architects state that this is the wrong reason to use an ORM. Being comfortable with relational databases and SQL are requirements for using an ORM. One of the major reasons that databases succeeded is the pure power of SQL. How about if we could harvest the power of SQL, ADO.Net , the OOP concept and bring them together in a powerful visual mapping studio that allows automatic generation of data services code based on the visual mappings between database columns and objects? Is that a compromise or an improvement? Some debate that objects to query syntax is very complicated and they prefer to deal directly with SQL. It is also a fact that database administrators can participate in the optimization of SQL if they had easy access to it. The concept of a Mapping is a one compilation unit that is composed of two sub units; one being the SQL statement and the other the model object that translates into a method in the data service class. If both of these units are edited by their own visual editors then tuning should be a breeze. Mappings are part of a project and the project compiles to a data access library. In this case the data tier grows based on the application requirements and the data services themselves can be distributed in different projects. The application services have a choice to link to the data tier libraries that they need. Simply reference the libraries and access your data. If we have a choice to custom create and fully control the data services in terms of maintenance and growth, modularity and abstraction, benchmarking and round trip engineering, in an IDE that finally focuses only on all of these requirements of the data tier, should we consider it? Even if we choose an ORM that is not custom, could we use this in addition to that?

Orasis software introduces the custom IDE data services crafter, the Orasis Mapping Studio 2009 and it provides the choice to utilize the better of the two worlds. Relational databases and class hierarchies should not relate as the ORM implementation specifies but they should relate on what the business requirements are. True mapping of objects to SQL should address object graphs at any depth level. If an object graph has contained members of abstract classes and interfaces, the mapping process should allow implementation classes of these instances to be replaced. Even contained members that are instantiable classes should be allowed to be replaced by derived ones. Data architects and developers can now orchestrate the development of the data tier layer and guarantee performance. The benchmarking features of the IDE on the data services code and the SQL perform the ultimate test. The ability to drill into any mapping through a visual editor to modify/enhance it reveals a powerful feature that needs to be taken into serious consideration. No system goes into production before it is tuned.

Can a traditional ORM technology that generates model objects that map one to one to a database schema satisfy all the needs for data access in a system? Or even a more enhanced approach of an ORM like Entity framework that still shares the majority of the features of a traditional ORM can satisfy all of the needs of a true isolated database tier that targets performance in the enterprise?
The flexibility to map easily database fields to object properties in object graphs, auto generate custom data services layer code with no introspection code and validating it's performance without having to write tedious testing code for it, in now an option.

Orasis Mapping Studio and ORM Layers

2008-07-23T12:12:38-05:00

For those who are not clear how the Orasis Mapping Studio (OMS) differs from other ORM Layers, here is a brief comparison.

1. OMS is a custom Data Acess Layer Code builder, while other ORMs are frameworks.
This means that OMS generates all the code that is needed to populate your .NET objects from a database based on the Queries and Mappings that you created in the studio. Once the code is generated, its yours to keep and use and has no dependencies on any Orasis Software Libraries or frameworks.

2. OMS keeps the Objects and the Database Schema loosely coupled.
ORM and other Data Mapping Frameworks map Database tables into Objects directly, creating a tight coupling and one-to-one mapping. This creates a tight dependancy between the two worlds, the Object Oriented world and the Relational world. OMS lets you keep the Object design and Table schema independant, marrying them only through SQL queries and parameters. Changes can be made to the Objects or Database Schemas without causing ripple effects in the other.

3. Zero Learning Curve.
ORM and Data Mapping tools require developers to learn new Query languages such as OQL (Object Query Language), new framework functionalities, new configuration constructs and attributes, etc. OMS does not require the learning of any new languages. It uses SQL and generates .NET code, both of which familiar to most .NET database developers. There are no configuration files, no framework libraries to call, and no decoration attributes at all.

4. Performance, performance, performance!
OMS is designed to let you maximize the performance of your data access layer. OMS allows you to customize your queries with efficient joins and supports dynamic queries (queries with parameters) for filtering data so you only retrieve what is necessary and lets the database engine do the hard work of caching, parsing and reading rather doing it in code. This adds significant speed to your data access layers. The OMS allows you to test run your queries and .NET Mapping methods within the IDE to see what the performance of your data access layer actually is, in SQL execution time and .NET code execution time.

The fundamental difference between ORM and Data Access Tools compared to OMS is that, ORMs use introspection and reflection at run time to populate data into Objects. This is costly since introspection and reflection are known to be slow operations. In a realistic environment where there are hundreds and thousands of rows being fetched, the performance degradation adds up. OMS shifts this work upfront in design time. All the reflection is done in the IDE to view your .NET assemblies and Database Schemas to perform mappings. Once the mappings are done and the code is generated, the code is free of introspection and reflection code. If things change you simply remap and regenerate the code.

5. Testing. OMS lets you test your data access layer before you release it for other developers to use it. You can generate the .NET code for your data access layer, and test it within the IDE in reflection mode to see how it is performing and what is the data that is coming back. This tests data accuracy and speed. With ORMs you can see your mappings, but you cannot run them and see what Queries are being generated and what data is coming back, and how it is performing. You must set breakpoints and spend tedious hours capturing SQL Queries though a logger and inspect your objects to see what data is in them. This feature of the OMS adds to confidence that the data access layer is working when it is complete and also improves development time where all the testing can be done with one click of a button and the results are infront of you in one IDE

6. SQL. I cannot stess this any more that SQL is a powerful language which databases understand. No query language can abstract it or make it easy without diminishing its power. The OMS has an easy to use SQL designer with Intellisense support to make writing complex SQL queries a breeze. ORMs translate database schemas into objects so that they can provide Object Query Languages and intellisense. Object Query languages cannot perform all the operations of SQL and cannot guarantee efficient queries. To optimize Object Query Languages it requires changing the schema or mappings which will have adverse effects on other parts of the system.

To summarize, I will say yes ORMs have provided ease and flexibilty for developers that they had not seen before. But the OMS is a tool built by developers for developers who are tired of the plethora of ORM solutions that all have the same fundamental problems. The OMS has been tested and proven in real world scenarios and consulting projects, many times replacing ORM layers or working with ORM layers side by side. It is a fresh and proven approach to developers who are serious about mapping their database to their obejcts, with the ease and flexibility of ORMS but without the problems.

Orasis Mapping Studio Forum Launched

2008-06-23T10:13:36-05:00

Please post any technical questions or comments about the Orasis Mapping Studio here.

Thank you,

Orasis Software Support