Frans/All,

I have read a lot of Frans writing (via forum and Usenet posts) about Entity (Chen's) vs. Domain Driven Design.

Frans prefers the Entity model, and I believe that LLBLGen was designed with this approach in mind. To date, I have only used this approach. My understanding of the difference between the Domain and Entity approaches is that behavior is part of the business object in the Domain approach, and behaviors are kept separate from the business object in the Entity approach.

(Frans or anyone, please correct me if any of the above isn't accurate--I don't want to misrepresent you or the product).

My question is: is there any reason why you couldn't use the LLBL Entities as the base objects of a Domain model? Could you simply inherit from each Entity and add required behavior?

I'm getting this question a lot internally, and want to make sure I answer it correctly. I'm not asking which approach is better--I simply want to know if it's possible, and if people use LLBLGen with the Domain approach.

Question #2 (almost completely unrelated):

I started wondering about this when pondering the new EntityView object. My understanding (I haven't played with V2 yet--I've only read about it) is that you can now filter and sort this object in memory using existing predicate and sort expressions.

So, assume I have a multi-layer application. I have a utility class for predicate expressions--it creates and returns a predicate expression based on a parameter passed in. So if I have access to this utility, I can create this predicate expression and use it both to filter the database and to filter the in-memory entities. Very cool!

My question is, in what project/assembly would I put this utility class? The only project that every layer has knowledge of is the DAL generated from LLBL. Is it a good practice to add files to the generated projects? Would it be better to create a separate utility project that every other layer also has knowledge of?

Thanks for any insight.

Phil