Hi, LLBLGen does not force me to inherit my business objects from a framework base class (let's name it PersistentObject). I have the feeling that this is good because it gives more flexibility.

However, I am missing a concrete example, where it would be bad to be forced to inherit from an O/R mappers framework base class.

Can you please name one or two concrete examples, where it pays that business objects created by LLBLGen do not force me to inherit from a base class belonging to LLBLGen?

Thanks for your help.

Regards, Mario

mario.muja wrote:

Hi, LLBLGen does not force me to inherit my business objects from a framework base class (let's name it PersistentObject). I have the feeling that this is good because it gives more flexibility.

All generated classes are inheriting from base classes, like EntityBase (selfservicing) or EntityBase2 (Adapter).

However, I am missing a concrete example, where it would be bad to be forced to inherit from an O/R mappers framework base class.

Can you please name one or two concrete examples, where it pays that business objects created by LLBLGen do not force me to inherit from a base class belonging to LLBLGen?

All entity classes are inherited from an LLBLGen Pro base class. The main reason for this is code re-use. The entity base classes are very feature rich and contain already all plumbing code so you don't have to write that yourself. You might think that you gain something with classes not inherited from a common base class, but you then also have to implement ICustomTypeDescriptor to make databinding in webgrids possible (you'll otherwise get all properties in a class show up as columns), all design time databinding code, ITypedList and IBindingList on your own typed collections to make sure the properties of an entity are showing up in a databinding scenario, your own ReadXml and WriteXml methods, your own IEditableObject implementation so you have rollback functionality in databinding scenario's etc. etc.

Every time I hear someone say: "I think it's better to have my own classes mapped to database tables, and no common base class", I really wonder how they define 'better' and why they think it's better. It will force them to write a lot of code which is now available for free, and trust me, databinding related code and xml producing code is not the code you want to write .

Why is it better, could you please give me one example why it is better? If you want to make the case of "I can then easily swap O/R mapper frameworks if necessary", I think you're mistaken, as every O/R mapper on .NET uses a different query language/mechanism. So if you're using O/R mapper XYZ now, and want to move to O/R mapper ABC , you have to re-write a lot of code as well.

Of course, using your own classes in the presentation layer (PL) makes that PL O/R mapper agnostic. But that has a high price, as in the PL you'll need features not available to you in your own code, you have to write all that code which is already there in the common base class offered to you in most common O/R mapper frameworks. Why re-invent the wheel and make the project more complicated? Life's complicated enough.