The Ancient Art of Programming

This is my first post on Neo (.NET Entity Objects), a framework for .NET developers who want to write enterprise applications with an object-based domain model. I have been using Neo for little over a year now, and it has suited me perfectly for my .NET ORM needs. To further quote the website:

Neo includes tools that create an extensible object-based domain model as well as the database schema from a an abstract description of the model. At runtime, rich schema information is used to dynamically generate all SQL required for object persistence management. Being based on ADO.NET data sets, a Neo domain model is independent of the actual backing store and works equally well with databases and objects in an XML representation.

One of the nicest features features of Neo is that it encourages you to place the business logic in the domain objects. As developers, we have been thought good object-oriented practices such as data abstraction, information hiding, encapsulation, inheritance, polymorphism. It almost seems that we forgot about these principles when we started to make Enterprise software: in both J2EE land and .NET, I often see the following architecture:

1. Data layer, which contains value objects with just properties,
2. Business or service layer, with Manager or Service classes that manipulate the data objects
3. Presentation layer, which calls the business layer

This not a object-oriented architecture (which combines data and process together), this is a functional architecture. Why should we give up on our OO-practices? Because we want to store something in a database? Shouldn’t that be just a matter of serialization…

As counter-argument, I am often told that enterprise-like features such as security, transactions, or auditing cannot be implemented when using a behavioral domain model. Thus, what you see is that the infrastructure of the project is often more important than the architecture; it seeps through the design. Martin Fowler calls this the Anemic Domain Model anti-pattern.

I think that this is wrong: the infrastructure should be a thin layer on top of the architecture, and never influence it. And to end this post on topic: Neo nudges you in the right direction: for every entity, it generates two classes: a value-containing base class, and a behavioral subclass that you are supposed to edit.