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.