DataObjects.Net is intended to be used as transparent persistence layer for persistent business entities. It completely solves a set of typical problems of ADO.NET-based solutions, including:

• Building\updating the database schema;
• Implementing DAL (data access layer). DAL contains all persistence-related services for BLL (business logic layer). DataObjects.Net provides a transparent DAL with intelligent caching.
• Import\export layer implementation. Import\export layer should be able at least to save a part (or all of) of business entities to external file and load them back. Usually this part is used to implement Save, Load, Cut, Copy, Paste, Undo and Redo operations;
• Provide remote access to your business entities and services. This feature usually required to simplify integration with other enterprise systems;
• Common full-text indexing and search layer is necessary in almost any application now. ADO.NET doesn’t provide any unified way to transparently update per-object full-text data; moreover, sometimes it isn’t enough to use full-text indexed columns spread over several tables, since SQL Server is incapable of executing a query against multiple full-text indexed tables.
• Common access control system becomes necessary with increase of the number of user roles – per-object security restrictions (in comparison to per-table restrictions offered by SQL Server) in combination with more simple access control methods allow to describe most of real-life access restriction scenarios.

Small size project case

Gartner Group estimates nearly 40% of the effort is spent on implementation of persistence-related services for the application (so 40% of the effort is spent on solving of just first 2 mentioned problems).

Let’s assume:

• We implement small size project, estimated number of man-hours is 500 (approximately 3 man-months);
• Average man-hour costs the company $30 (so our developers are relatively cheap);
• 3 developers are planned to be used in the project.

So the total cost of this project for the company will be:

500 m-h * $30 = $15000

And approximately 40% of time will be spent on solving persistence-related problems, so the cost of this part is:

$15000 × 40% = $6000

With use of DataObjects.Net the necessity to implement all persistence-related services will be completely eliminated. In order to use DataObjects.Net in this case we need 3 DataObjects.Net Standard Edition licenses, so the total cost of licensing DataObjects.Net is $750. We saved:

$6000 – $750 = $5250

So it will be efficient to use DataObjects.Net in a small-size project even if we’ll spend ~ 1 man-month on studying it (~ 1/3^rd of time we have on it, or ~ $5000).

Average project case

Let’s assume:

• We’re implementing average project, estimated number of man-hours is 3360 (20 man-months);
• Average man-hour costs the company $30;
• 5 developers are planned to be used in the project;
• All mentioned (typical) problems should be solved.

DataObjects.Net claims to save up to 50-60% of development time in this case, and we hope you’ll find this statement very close to true. Nevertheless let’s keep it on the same level of 40%.

The total cost of this project for the company will be:

3200 m-h * $30 = $100800

In order to use DataObjects.Net in this case we need 5 at least DataObjects.Net Standard Edition licenses. Assume we decided to buy Enterprise Edition license to get the source code of the product and high priority support, as well as ordered 5-day training for the faster startup. Let’s calculate the total cost of this option:

• $2195 + $199 = ~ $2400 – the cost of licensing DataObjects.Net (1 Enterprise Edition License Pack for 4 developers + 1 Standard Edition license for one additional developer according to our licensing policy).
• $3200 – the cost of best training we can offer currently (5-day, for up to 6 developers)
• $1000 + $200 × 5 = ~ $2000 – additional trainer expenses (flight, hotel, etc. – average)
• 5×40 * $30 = $6000 – a cost of spending the time of 5 developers on one-week training

Total:

$13 600, or approximately 13.5% of the total project cost.

We saved:

$100800 × 40% – $13600 = $26700, or approximately 26.5%

Notes:

• 3-day training (rather then 5-day) is fully enough if developers are fully familiar with .NET Framework and RDBMS concepts (such as transactions, isolation, locking, etc).
• You may spend just ~ $1700 on licensing DataObjects.Net in this case (one Professional Edition license + 4 Standard Edition licenses), and don’t spend anything on trainings, but it’s probable that this model will be less efficient (imagine that your team will spend two weeks on studying the product, rather then one)

Further potential savings

t’s well-know fact that almost any application is implemented iteratively. The follow up costs over the whole cycle of lifetime are usually much higher than initial development cost. DataObjects.Net significantly reduces these costs, since:

• Its use leads to more concise and better structured code:
  • Persistence information is always known from type definition (forget about any mapping)
  • All business code is located within persistent types or business services (so business layer is obviously separated from other parts of the application)
  • No any „begin transaction – commit\rollback“ – like code: just apply attributes provided by DataObjects.Net
  • There is much less error-handling code, since any exception is processed by automatic transaction handlers provided by DataObjects.Net first
  • All references to other persistent types and large objects (e.g. BLOB data) are resolved transparently – it isn’t necessary to load referenced\load-on-demand objects manually
  • You shouldn’t worry about removing references to removed instances – this task is always performed completely automatically and transparently for you
  • No any caching-related code – DataObjects.Net caches almost anything transparently in global and Session-level caches, as well as ensures that only actual cached information is used (so no any cache expiration checks are necessary)
  • You shouldn’t worry about support for multiple database servers: DataObjects.Net already supports most popular ones (currently Microsoft SQL Server 2000 / 2005 / MSDE, Microsoft Access, Oracle, Firebird and MaxDB / SAP DB are supported)
• Forget about updating your database schema:
  • DataObjects.Net automatically handles database schema updates
  • Updated database is always referentially consistent (i.e. won’t contain references to removed objects\object types)
• It’s much easier to work solely with classes (code), rather then constantly update the following parts to keep them in sync:
  • Definitions of persistent entities and BLL code (this is the only part you should worry about, if you’re using DataObjects.Net);
  • Update the DAL (data access layer)
  • Update the database schema (add\create\update tables, columns, indexes, primary\foreign keys, full-text indexes, etc.).

It’s quite probable that you may get the same 40%-50% economy reducing both the cost and the time necessary to implement new requirements.