Entitiy as Composable Part of Domain Object

Posts   
 
    
psandler
User
Posts: 540
Joined: 22-Feb-2005
# Posted on: 07-Oct-2010 00:43:32   

Here's a thought I've been kicking around for a while, and I'm wondering if anyone else does it this way, and if so, how effective it is.

I generally use LLBL Entities and Collections out of the box, and use them across all layers of my applications. In some cases I will add to them in certain ways using partial classes, for example to add interfaces, convenience methods, and/or wrapper properties (usually to conform to added interfaces).

Some developers prefer to avoid what Fowler calls the "anemic domain model", where entities contain only data, no behavior. I personally don't have a problem with my entities being anemic, as I tend to take a service-centric approach to designing my architecture (by service-centric I don't necessarily mean SOA). However, as I said, some developers don't like to take this approach and for this reason are resistant to using LLBLGen.

It seems to me a simple solution to the "anemic data model" is to use LLBL entities and collections as a composable part of another class. So this other class would really be the "domain object", and the entity would be a member (and property) that represented the data aspect of the class. Where is it written that the object(s) that represents the row(s) in the database needs to be the main domain object? By my definition, a domain object is basically any object that represents data and/or logic to address the problem space.

So these domain objects that contain the entities could also have methods that perform calculations on the data/entity or act on them, and services (even injectable services) that also represent behavior.

Has anyone used this or a similar approach with LLBLGen?

Walaa avatar
Walaa
Support Team
Posts: 14983
Joined: 21-Aug-2005
# Posted on: 07-Oct-2010 09:52:26   

This is perfectly fine. LLBLGen entities are Low Level Business Layer objects and hence the name LLBL.

In the past we had "Manager Classes" templates published in our download section. But these were 3rd party component that has never been ported to the latest versions.

That's to say, the concept of using LLBLGen entities as low level objects is perfectly valid.

Also the other way is also valid (I usually follow that myself), where the logic is inside some service layer not inside domain objects.