The Object to Relational Mapping Problem and the Orasis Approach
|
October 2008 Summary: This articles attempts to identify the problems that exist in the arena of mapping between Objects and Databases and how the Orasis Mapping Studio provides a robust and flexible solution to alleviate the problems of database application development in an Object Oriented platform such as .NET. Contents What is a Mapping? Current Mapping Approaches The Orasis Solution |
||
Data Mapping is the association data between two disparate data models. In this article will refer to mapping in terms of associating Object models and Relational Databases. Current Mapping Approaches
Currently there are wide variety of approaches to mapping databases and Objects provided by many vendors and open source technologies. We will discuss the most common ones and their pros and cons. ADO.NET and DataSets The simple and straightforward approach is to retrieve data from databases into applications by using Microsoft's ADO.NET with built-in data objects such as DataSets and DataTables. These objects have good code-generation support, can be stored as XML, and make it very easy to get data presented very quickly. On the surface, these are pretty good reasons to use DataSets and DataTables but many developers just don't want to drag ADO.NET DataSets all over the application. Developers also don't want a one-to-one correlation between database fields and class fields. ADO.NET and Custom Objects Because of the overhead most developers prefer to use the ADO.NET DataReader with custom objects and custom queries for speed and flexibility. With this method developers gain more control of their database access and mapping layers. Custom objects provide a lot of advantages: 1. Flexibility: Developers are free to execute custom queries or stored procedures and populate custom objects from resultant recordsets. 2. Light weight: The objects are typically light weight, able to be passed between different tiers of the application, whether in-process or out-of-process. They have low memory footprint and don't have database-access logic embedded in the objects. 3. Usabilty. Custom objects will be built, whether programmers are using a database or not. They will be used for a variety of purposes besides mapping to databases. 4. Custom objects can be returned as XML easily (serializable): They can be easy serialized and converted to XML for Data Services or Web Services. 5. Data-Access Layer: They could be populated by data access layers or frameworks through configuration or code-generation. 6. Code Generation: They can be easily generated either through code generation tools or designers. OR/M Framework Approach This approach is gaining wide interest in the object to database mapping area. It uses data access frameworks also known as Object to Relational Mapping (ORM) layers. These technologies provide a Model based approach where Object Models or Entities are mapped to Relational Schemas. There are numerous implementations of ORM layers such as NHibernate, Microsoft's LINQ to SQL, ADO.NET Entity Framework and many other commercial technologies. This approach is hailed by many pundits, as being the answer to the Object - Relational impedance mismatch and cleaning up your object to relational mapping. Although the concept is appealing and has provided great strides in making relational data mapping more manageable, abstracting database code from business code, and providing a standard view of databases regardless of implementation, it comes with some debilitating drawbacks when implemented in real world projects. Some of the issues the developers face when using this approach are: 1. Configuration: These technologies require configuration files to map table schemas into object structures. In large enterprise systems the configuration grows very quickly and becomes extremely difficult to create and manage. Maintaining the configuration also gets tedious and unmaintainable as business requirements and models constantly change and evolve in an agile environment. 2. Custom Queries: The ability to map custom queries that do not fit into any defined object is either not supported or not recommended by the framework providers. Developers are forced to find workarounds by writing ad hoc objects and queries, or writing custom code to get the data they need. 3. Proprietery binding: These frameworks require the use of proprietary libraries and proprietary object query languages that are not standardized in the computer science industry. These proprietary libraries and query languages bind the application to the specific implementation of the provider with little or no flexibility to change if required and no interoperability to collaborate with each other. 4. Object Query Languages: New query languages called Object Query Languages are provided to perform queries on the object model. They automatically generate SQL queries against the database and the user is abstracted from the process. To Object Oriented developers this may seem like a benefit since they feel the problem of writing SQL is solved. The problem in practicality is that these query languages cannot support some of the intermediate to advanced SQL constructs required by most real world applications. They also prevent developers from tweaking the SQL queries if necessary. 5. Performance: The ORM layers use reflection and introspection to instantiate and populate the objects with data from the database. These are costly operations in terms of processing and add to the performance degradation of the mapping operations. The Object Queries that are translated to produce unoptimized queries without the option of tuning them causing significant performance losses and overloading of the database management systems. Performance tuning the SQL is almost impossible since the frameworks provide little flexibility over controlling the SQL that gets auto-generated. 6. Tight coupling: This approach creates a tight dependency between model objects and database schemas. Developers don't want a one-to-one correlation between database fields and class fields. Changing the database schema has rippling affects in the object model and mapping configuration and vice versa. 7. Caches: This approach also requires the use of object caches and contexts that are necessary to maintain and track the state of the object and reduce database round trips for the cached data. These caches if not maintained and synchronized in a multi-tiered implementation can have significant ramifications in terms of data-accuracy and concurrency. Often third party caches or external caches have to be plugged in to solve this problem, adding extensive burden to the data-access layer. We can see that there exists is a mismatch between software pundits and developers when it comes to mapping Objects and Databases, which is why there exists a "mapping mayhem". Pundits have advocated frameworks and data layers which provide a one size fits all solution, while developers like to be in control and develop according to the requirements and demands of the users. Developers have asked for Code Generators that are able to generate a thin Data Access layer that retrieve and persist their business objects without having the unnecessary overhead in the objects and without having to use heavy frameworks and new query languages. Combining the Two Approaches The frameworks and OR/M layers definitely provide benefits such as strongly Typing your data access and abstracting database code completely from business code, while manually writing all the mapping code provides greater control, speed and flexibility. The combination of these two approaches seems to be obvious as the optimum solution for the mapping problem. This is where the Orasis Mapping Studio offers a new approach to map the two data models and provides a clean and robust solution. |
Orasis Mapping Studio is built from ground up to offer developers finally what they have been asking for. A visual mapping tool with a code generator that builds a thin data-access layer to map objects to queries. It takes the complexity out of mapping, isolating database code from business code and eliminating any unnecessary overhead! It is a comprehensive database access engineering tool that provides all the features necessary to put this approach into action. It provides the users a Data-Driven model to build Mappings for reading and persisting Objects from databases. Users can create custom associations between data from a SQL query and their objects and call it a Mapping. Mappings can be to read data from the database into Objects using Select Queries or persist data from Objects into Databases using SQL Insert, Update and Delete Statements. The focus of the Orasis approach is on the database access layer and not on the Model Objects or Database Schemas. Design Time vs Run Time: The Orasis approach shifts the tedious work of Type Reflection and Introspection and maintaining configuration out of the mapping layer or framework into a GUI that lets users do all the mapping work at design time instead of runtime. All that information is then saved and used to generate the specific code to get the job done. Once the data-access code is stripped off these overheads, the benefits become clear: 1. No configuration is required to be maintained and used by the consumer application. It can simply access the class libraries that have the code already built according to the mapping. The code can be regenerated as the project changes. 2. Non - proprietary: All the code is generated using pure .NET and base ADO.NET Interfaces. The only dependency besides the .NET framework is the Database Provider and the user's Object Assemblies. 3. No reflection or Introspection: The generated code directly instantiates the required objects with 'new' statements instead of using Reflection libraries. The properties are set with direct set expressions instead of introspection method calls. 4. Mapping Management: All the Mappings are stored in a project file that can be managed and edited in an IDE as requirements evolve using the Agile method. 6. No new technologies to learn. The learning curve is greatly reduced as the Orasis approach builds on existing and proven technologies like SQL and ADO.NET which are commonly available skill sets. The Mapping Process The Orasis Mapping Studio treats mapping as a process rather than an atomic operation. The mapping process is straightforward. The user defines a SQL query to read a set of data from the database. The application parses and understands the query to expose its metadata visually to the user. This includes column names, data types, parameters and null-able flags. The user is then given the choice to select a Type to map the data to. The Type's metadata is reflected upon and exposed to the user visually. The user is then able to see both the mapping entities (i.e SQL and Type) next to each other and then map data fields between the two to build field mappings using drag and drop. All this information is gathered and saved as a Mapping. A Mapping gets translated into pure .NET code in a mapping method when the code generator reads the Mapping information and creates .NET code. The generated method's function is to bring both mapping entities (i.e SQL and Object) and map the associated fields as specified by the user. The resultant objects are then returned in a list for the caller to use. These methods are grouped into classes and assemblies to provide a complete data-access layer for a consumer to call and use. The mapping process for persisting data is similar to but the opposite of the read process. The user defines an Insert, Update or Delete SQL statement with parameters for object data. The query parameters metadata is displayed for the user to map them to the object's properties that needs to be persisted. The code is then generated to populate and execute the SQL Statement for each object that is passed in to be persisted. All the data mapping code that is generated can be taken from the Studio and embedded into the user's database application without any proprietary dependencies on the Orasis Mapping Studio. The code is clean, readable, and free from any configuration attributes or XML files. The Orasis Mapping Studio Features The mapping process is impossible to implement without the IDE that assists the user in each step and managing the data-access layer as a project. 1. Query Builder: A powerful Query Builder is provided for collecting and displaying database metadata to assist users in building even the most complex SQL Queries. 2. Type Reflector: Type Manager allows users to bring in Custom Objects of their choice from existing assemblies or generate new Class definitions from the Query results. When generating new Classes, each column or parameter from the query is created as a property in the Class and automatically mapped to the corresponding column. 3. Mapping Builder: A powerful mapping builder is provided to display the columns and parameters of the query next to the properties of the class and the user is able to drag and drop fields that need to be associated. Validation is performed at each association to make sure that field of incompatible data types are not allowed to be mapped. 4. Code Generator: Once the mapping is complete, simple code generation inputs are asked of the user such as the name of the method that will be generated for the mapping, any documentation comments and the class that the method will belong to. 5. Compiler: The built-in compiler compiles the SQL Queries and the generated code to generate Assemblies and verify the code syntax. 6. Unit Tester: Unit testing the generated data access layer is necessary to validate if the data is accurate and benchmark its performance. A unit tester is provided within the IDE to able to run the Mapping methods and view the object results and timings. 7. Integrated Development Environment: These features along with management and interactive IDE features gives the users full control of their Mappings and generated data access layer so they are able to achieve their Object to Relational Database mapping functions with ease. Stored Procedure support The question asked by developers is where do stored procedures fit in the mapping process? The Orasis Mapping Studio supports the use of stored procedures for performing mappings. They can be invoked and their results and parameters can be mapped to objects, similar to treating them as queries. This keeps the concept of mapping objects to queries intact, and provides a clean separation of database code and business code while leveraging the performance and power of stored procedures. |
|
|
Conclusion The features provided by the Orasis Mapping Studio have been carefully selected and designed to facilitate developers in building good, clean and efficient data-access layers. Minute details such as method documentation, IntelliSense, class grouping, code compilation and code navigation features have been provided to make sure that the developers get the code that they can read, manage and distribute. The Orasis approach has been put to the test and proven in real world projects to generate the most demanding mapping and database access operations needed. It has made developers think in terms of objects and queries and eliminate the overhead that is carried by frameworks and ORM layers. Its goal is to provide a bridge between the two data models without interfering with either one and introducing any dependency between the two. It is an innovative solution that has taken years of research and development with collaboration of seasoned developers and architects in the industry to build. |
||