Olero Software, Inc.
|Quick Facts: Inexpensive, well-featured object relational mapping tool specifically designed for .NET developers.|
ORM.NET from Olero Software, Inc. is an Object Relational mapping tool specifically designed for .NET developers.
ORM.NET handles the translation of your data objects to and from a normalized SQL database. It does this by creating a data access layer (DAL) from your SQL database schema. The DAL becomes the bridge between your .NET data objects and the database.
According to Olero Software, ORM.NET can reduce nearly 50% of the time it takes to build a data intensive application.
The steps I took to review ORM.NET version 1.4 were
- explore the resources on the Olero web site;
- download and install ORM.NET;
- complete the ORM.NET tutorial;
- test ORM.NET with the training database provided by Olero;
- test ORM.NET with a real database;
- test Olero support; and
- summarize my findings.
Explore the Olero Web Site
At the Olero web site it took me about an hour to read the introduction to the product, view the demo, take the product tour, and become familiar with the online help system. The site led me quickly - and gently - from ground zero to the point I felt ready and eager to download the product and get started.
Download and Install ORM.NET
I downloaded ORM.NET from the Olero site and installed it on my computer in less than 15 minutes. During the installation I installed the optional training database on my SQL Server. The download and installation process was simple and went without a hitch.
NOTE TO VB.NET Programmers - To use this product C# must be installed on your computer. Olero Software told me the next release - version 1.5 - will support native generation of the Data Access Layer in VB.NET.
Complete the ORM.NET Tutorial
Included in ORM.NET Help is a six-step Quick Start tutorial. The purpose of this tutorial is to acquaint you with the steps required to generate an ORM.NET DAL component and how to deploy it within a .NET application.
It took me 20 minutes to complete the Quick Start.
Test ORM.NET With the Training Database Supplied By Olero
After the Quick Start, Olero recommends working through the ORM.NET Help Sample Code topics. Included are basic examples which show how to retrieve, insert, modify, and delete using an ORM.NET DAL. There are also advanced examples which show how to: sub-class the DAL classes to add business logic, serialize data, use the ORM.NET Lookup Table object, and use the DAL as the DataSource for an ASP.NET DataGrid.
I created a Visual Basic.NET Windows Forms application to explore the code examples. I used ORM.NET to generate a DAL component (DLL) from the Olero training database. Next I created a Visual Basic.NET application. I added a project reference to the ORM.NET DAL component.
Using forms and controls I implemented the code examples to retrieve, display, bind, and update data from and to the Olero training database via my DAL component.
I did not need to use any ADO.NET code or embed any SQL statements in my application.
Test ORM.NET With A Real Database
To test ORM.NET with a real database I decided to use ORM.NET to partially replicate a data intensive customer service application which we created for one of our customers a few months ago. This application uses a DAL created with ADO.NET. The Sql Server database behind the customer service application has 42 tables. The database schema defines a primary key for each table and explicitly defines the relationships between the tables. This database uses good naming conventions, has indexes to optimize SQL operations on the data, and is normalized.
The first step in this test was to build an ORM.NET DAL from the real database. I used the ORM.NET Object Browser to connect to the database. I used the Object Browser to review and modify the way the tables and columns in the database would be mapped to data objects/data properties in the DAL component I was about to generate. I identified some tables as Lookup Table objects and some columns as required. I clicked the Generate Data Layer button in the browser. The database was validated and a DAL component was generated from the customer service database. This first step took about 45 minutes to complete. Most of this time was used by me to review the 42 tables. Once I finished my part, ORM.NET generated the data access layer component in seconds.
The next step I took was to build a Visual Basic.NET application. To it I added a reference to the customer service DAL component I created in step one.
Next I added forms to the new application. I added 10 forms from the original customer service application to the new project. These forms represented a variety of data access; data binding, display, data join, and data update processes.
I wired the 10 forms to the ORM.NET customer service DAL. In the original application the forms access data through data objects which are served up by a DAL we created with ADO.NET. In the new application I modified the forms to access data via the ORM.NET customer service DAL instead.
Overall the test forms required 46% fewer lines of code for data access than the same forms in the original application. In this test I had add a little ADO.NET code - a few lines - to handle some application specific requirements I could not handle directly by using the objects of the ORM.NET DAL.
Test Olero Software's Support
During the process of learning and testing ORM.NET I found most questions I raised could be answered by the Olero Software web site resources or ORM.NET Help.
I ended up with seven questions I could not resolve. I submitted the questions to Olero support in two different emails on two different days.
Both emails were answered in less than a day. The answers from support were clear and complete. All seven questions were answered to my satisfaction.
Summary Of The Findings
ORM.NET provided me with a very fast way to create a data access layer which separated the data objects in my application from the SQL database where the application's data objects are persisted.
ORM.NET reduced the amount of data access code my customer service test application required by 46%. It reduced the complexity of the application. It eliminated the need to rework the data access code when the database is changed. Based on these results I believe it will be possible to pay for ORM.NET the first time I use it to create a data intensive application.
The ORM.NET data layer was very intuitive to use with every method and property accessible using through Intellisense.
Olero Software's web site provided me with excellent resources for discovering, learning, and using ORM.NET. I found the site to be well organized and the content is well written and to-the-point.
The ORM.NET Help Quick Start and Code Samples topics provided me with enough training and information to create an ORM.NET DAL and deploy it in a real-world application.
Olero provided support that was quick and satisfactory.
** Important Notes **
Database Schema Requirements
Your database schema must meet two requirements to work correctly with ORM.NET.
- There must be a primary key in each table.
- Relations between the tables must be explicitly defined.
ORM.NET will attempt to validate your database schema. If your database schema fails to meet the schema requirements ORM.NET will provide a report which lists the items to be corrected.
Olero makes four database recommendations. These recommendations are best practices for any relational database. Implement these recommendations to optimize performance and usability of the data access layer you generate with ORM.NET.
- Do not use spaces or invalid characters within column names. These will be replaced with underscores in the data layer if you use them.
- Use singular names for tables and properties. This will make the data layer easier to understand.
- Design indexes with care to optimize performance.
- Follow common normalization methods.
About The ORM.NET Data Access Layer
ORM.NET generates a robust and flexible set of class templates which model a normalized relational data base. The generated class files are compiled as a fully functional .NET assembly (.DLL) which acts as a complete data access layer and extends the functionality of ADO.NET.
ORM.NET also generates a set of user-modifiable business objects, which derive directly from the data objects, and can be modified by the programmer to include custom business logic. By keeping your business logic separate, the data layer can be completely regenerated at any time.
All Transact SQL code is implemented so that developers can easily retrieve, modify, delete, and update data without relying on complicated stored procedures, views, embedded SQL statements, or complex data access logic (ADO, ODBC, OLE-DB).