ADO.Net Object-Relational Mapping

Why do architects follow patterns that enforce the data model to drive the development of the object model?

The problem appears to exist in two scenarios:

1. The conceptual/logical data model should proceed the design of the business objects
2. The physical data schema should drive the generation of the business objects.

These approaches are 100% wrong and can cause major issues in the development of systems.

The one to one object relational mapping that many technologies enforce do not take into consideration the impedance mismatch between the object and relational paradigms, and that this mismatch leads object and data practitioners to different designs. OOP developers apply different design techniques/patterns and concepts than the techniques and concepts that DBAs apply.  It is also very common that the DBAs always try to enforce the need for having them around after the data modeling is done and simply enforce application designs to be bound to their data modeling design. It is a fact that the people forcing this approach may not understand the implications of such a decision, or that there are better ways to proceed.

What are the reasons that an existing data model that map to an object model make it a bad design decision? Why do people do this?

Legacy database design poses technical constraints and may in fact have significant database design principals violated. If we create a one to one object relational mapping to the table schema, we also unnecessarily constraint our object model as well. Even in scenarios where the database schema is designed perfectly following all of the rules of referential integrity, the way we map objects can vary in many ways. Which is the right approach?

Let’s look at this example here: There is a possible database schema which defines shapes. As you can see the natural developer’s OOP view can vary significantly. Please note that this is only one object relational mapping view. As you can see mapping with inheritance is fairly straightforward, there aren’t any surprises. The classes simply obey real business entities and treat the data store as just a place holder. Orasis Mapping Studio simply allows you to import your business data models and simply map them to any level of depth graphically. Object relational mapping becomes a breeze developer does not need to worry about the ADO.Net code that bonds the object model to the relational data. A true Mapping IDE designed from the ground up that works on the principle of Mappings. True independent, free of any 3rd party dependencies and definitely not related to the tables but to your business. Orasis treats the concept of the database mapping as a first class citizen and applies principles that avoid the impedance mismatch and promote true OOP practices for the .Net enterprise. At any time the developer can remap a new type to an SQL query with a click of a button. Even SQL is created through a powerful designer that takes away the SQL complexities and promotes parameterized queries that translate to real OOP methods in a class that you define through the Mapping Wizards. Now you can create a Mapping for only what you need, when you need it. Have the freedom to marry your true business data models to the data store , do not allow the database schemas to dictate your object world!