Thoughts on ORM and the like

Monday, April 04, 2005

Upcoming Features

Multiple Employee-to-task Assignment

1.1.1. Overview

The purpose of this feature will be to allow the user to assign multiple users to the same tasks. In order to keep EP as simple and productive as possible changes to the database structure and application logic are necessary.

1.1.2. Implementation
A new table will be introduced to handle many-to-many relationships between tasks and users (in the same way it is done when assigning project members). The corresponding business entity, Task, will be updated so that now there is a collection of task assignees instead of a single one.

Changes to the task process flow will include:
1) Changing the project member list on the task details page to a check-box list to include/exclude task assignments
2) Changing the notification logic to take into account that there can be a number of task assignees
3) Time entry details page logic
4) Task Navigator logic
5) Information about assignments on bug and request list details pages
6) Reports

Search Module Description

The search module will allow the user to enter an arbitrary string, and the system will return projects, tasks, bugs, requests, and time entries which contain the search string in the title and/or description.

In order for the module to be as database-independent as possible, we will not use the full-text search capabilities of SQL Server. Instead, we will retrieve full tables from the database and use .NET DataView search features to filter the rows we need.

The module should provide 2 search modes, Simple and Advanced.
In the simple mode, the user only enters the search string, and the system looks for it in all relevant tables.

In the advanced mode, search targets can be specified (tasks, bugs, etc.), object submittal date range is available and should be taken into account if the user selects at least one date, and there is an ability to specify the assignee.

Thursday, March 17, 2005

Lo-o-o-ong way

Hi there,

Finally, EP.NET 3.1 is out. Even Mozilla FireFox is supported now. This version combined the speed of 2.8.4 with the feature-list of 3.0.

We're moving forward. Currently, I am prototyping the new features that will be included into 3.2. The next beta release is scheduled to mid-May. I will be posting feature descriptions here as I move along.

Thursday, February 03, 2005

New message

It's been quite long since I wrote to this blog. We're working hard on transferring 3.0 features into 3.1. It seems that the core functionality is settled and fixed, and now it is just a matter of implementing the old features in new terms :)

I've been thinking of implementing locking mechanisms for Easy Projects .NET. We are very likely to do it in one of the next minor releases, among other features. I'll be posting an article on locking here soon.


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.