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?
