ADO.Net revived. Why now visual crafting of your data access tier seems the right solution. Start mapping not coding!

Craft your database access API visually.

Visual creation of your database access tier seems more attractive than ever today. Simply drag, drop, click to auto generate your database access tier. Test your actual data access code without writing either the data access code or the tests. Orasis Mapping Studio 2009 makes it all possible.

Utilize the power of ADO.Net but do not write it.

Writing ADO.Net code can be a tedious job but given the right tool to auto generate it makes it a comeback. The hassle of writing ADO.Net and creating queries by hand is nullified with one comprehensive solution.

Use an ORM but not with the drawbacks.

Yes an ORM solution has a lot of drawbacks. It is time to face reality. Orasis allows you to ORM but in a more easy way. Visually map your queries to your object graphs. Simple as this.

Object Query languages; LINQ-SQL, HQL Are they easy to use?

ORM implementations of different flavors that introduce object query languages and auto generation of not so optimized SQL underneath the hood can cause development time delays and substantial performance issues. This is a proven fact and developers are starting to realize that maybe they should be looking somewhere else. Data access plays a vital role in business applications; and performance is one of the key factors to consider in any data-intensive application. There are many factors that can affect data-access performance negatively, such as network load, load on the database server, un-optimized SQL, and so on. Apart from these, there are other factors to consider with respect to the various data-access operations that most applications perform, such as opening and closing a connection, fetching a result set, blob access, and metadata retrieval, utilization of reflection/introspection, need for distributed object caching, etc. First of all, I have never seen a real enterprise system that involves fair amount of database access going into production without optimization. During regression testing, different operations show their true colors especially under load. That is when engineering teams jump in and try to optimize SQL and data access code. If the code was written by utilizing some object query language, the question remains on how you optimize performance since the SQL is generated dynamically by the ORM engine.

ORMs always perform faster?

Some developers support that ORMs perform faster even though:

ADO.Net is the most direct access to the database.

ORMs usually need an Object cache to offer compatible performance.

Ignore the fact that reflection/introspection versus direct access of model object properties is very expensive.

The illusion of avoiding SQL.

So why is this happening? It seems that the fact that developers think they do not have to deal with SQL makes ORMs so attractive that all of the overheads associated with them simply vanish. The truth is that object query language constructs are not easy to understand and use either, so developers end up writing the query but in a different language. Looking at a fairly involved object query code snippet one realizes that the object API is not for the average developer. This is where ROI kicks in and on a large scale system the time simply adds up to a lot of money and frustration. A related article that explains the ROI can be accessed at http://forums.orasissoftware.com/comments.php?DiscussionID=7&page=1#Item_0

Classes to table Mappings. Is this what we want?

Even though most ORM implementations force a one to one mapping of database tables to Classes, it seems that not many people object this practice. So let me understand this; we are using an object query language to abstract us from the database but our model object match the database tables 100%?

Since when my business object model should resemble my physical storage? Isn’t that a disadvantage? Should I waste time talking why is a bad practice? I guess not since it is a fact.