Thoughts on ORM and the like

Thursday, January 13, 2005

Performance struggle

Having an Identity Map inside the ORM framework handles the first level of caching the objects - a request for the same object does not travel to the database twice. The second level is to cache 1-to-n references (and make them lazy-loaded). However, there is one more scenario when the performance can be boosted.

Very often we need to show tons of records in a simple datagrid with sorting and filtering. We've had some performance testing, keeping in mind that a decent web application should render the requested HTML page in no more than 2 seconds. In previous version of EP.NET we used to bind the object collections to the list pages (e.g. Project List, Bug List, etc). This proved useful to have some logic during the data binding.

However, this approach cannot be used to archieve the 2-second goal. This is because the collection items are lazy-loaded. That is, their external references, like a reference from the Project object to the associated User object (representing the PM) are not loaded until requested, resulting in a number of additional trips to the database when it is not really necessary.

In an n-tier application (like EP.NET) there always are more or less separate layers, and the presentation layer is one of them. Take a look on what happens behind the scenes when the grid with the request list is loaded:
1) The GUI asks for the available request list
2) The business logic layer decides which projects should be included in the list based on user's permissions and routes the request to the data facade
3) The data facade retrieves the dataset from the provider and converts it to the corresponding collection of objects (RequestCollection in this case) and returns it to the GUI for the data binding
4) The GUI binds the collection to the data grid

Actually, the GUI layer does not need the collection for anything except the data binding, so why make it struggle with additional query requests?
In EP.NET 3.1 we decided to create a customizable query builder which will automatically create complex queries (with sorting, filtering and joining) based on XML query description. This approach not only proved almost the fastest possible way to display a list of objects in the GUI, but also a good foundation for the report generator we'll feature in 3.2. For now, the response time does not really depend on the number of records in the database.
Now, the GUI asks for the request list and receives a dataset with all the required fields read from the data source in one query. With SQL Server it is as fast as a lightning!

Wednesday, January 12, 2005

To inherit or not to inherit?

The first question that arises when a developer starts to create the business entities is whether to have a base class for all of them, or to implement a "domain object" interface (usually defined by the ORM framework). In Easy Projects .NET we follow a combined approach.

Mirrorm provides both the "domain object" interface, IDomainObject, and a base class, PersistentObjectBase. The base class provides ways for caching and retrieving 1-to-n references.

In EP.NET we feature a base class, Entity, which inherits from PersistentObject, and implements IDomainObject, because virtually all entities have the same implementation. It is the parent class for projects, tasks, bugs, requests, and all the rest.

Monday, January 10, 2005

Releasing version 3.0

We're releasing Easy Projects .NET (EPNET) 3.0 today. This will be the last version which doesn't take full advantage of ORM. The next release (namely, 3.1) will introduce a whole new architecture with transparent persistence, very-very-very improved performance, and what not :)

Behind the scenes, EPNET 3.1 will use our in-house product, Mirrorm (reflective ORM). It concludes our experience in developing n-tier applications for the .NET framework and has already been used and proved reliable in a number of solutions.
In the next posts I'll show how a sophisticated software product may benefit from using an ORM framework, such as Mirrorm.

Version 3.1 of EPNET will mainly be a refactoring release where we will solve the problems that are now before us:
1) Performance
2) Scalability (there will be a Windows.Forms client for EPNET sometime)
3) Customization ease

Hello, World!

This is the first message in my blog, where I will post the problems and solutions I am constantly facing in developing our flag product Easy Projects .NET (