Hi!

What is the best practice for extending sub-types in custom entity classes?

If there is (abstract or not) CarEntity which is super-type for example SportsCarEntity, and there is CustomSportsCarEntity which is extending SportsCarEntity, should there also be CustomCarEntity?

Thanks. Vladimir

Please refer to the folllowing sections in the LLBLGen Pro v.1.0.2005.1 documentation

1- Concepts -> Entity inheritance and relational models 2- Designer -> Inheritance mapping

Please get back to us if this didn't address your questions.

Good Luck

I was thinking about the following scenario:

Generated classes:
namespace EntityClassess
{
public class CarEntity : EntityBase2, ...
{...}

public class SportsCarEntity : CarEntity,...
{...}
}

My classes (not generated):
namespace CustomEntityClasses
{
public class CustomCarEntity : CarEntity, ICarFunctionality
{...}
}

namespace CustomInterfaces
{
public interface ICarFunctionality{}

public interface ISportsCarFunctionality : ICarFunctionality
}

I know it should be:

namespace CustomEntityClasses
{
public class CustomSportsCarEntity : SportsCarEntity, ISportsCarFunctionality
{...}
}

But, I also need to have

namespace CustomEntityClasses
{
public class CustomSportsCarEntity : CustomCarEntity, ...
{...}
}

because of CustomCarEntity implementation of ICarFunctionality.

     Vladimir

That's multiple implementation inheritance, and that's not supported in .NET. Multiple inheritance is actually about 2 things: multiple type inheritance and multiple implementation inheritance.

Multiple type inheritance can be achieved with interfaces. Though multiple implementation inheritance can't, you can always inherit from just one class. You can implement multiple interfaces but you then have to implement these interfaces manually.

In v2.0 I've planned to optimize this for you.

Otis wrote:

That's multiple implementation inheritance, and that's not supported in .NET.

I know, so I didn't post code that does multiple inheritance. In the example I posted, it seems to me that everything leads to mixing region usage in templates and "custom" inheritance. I wanted to get other opinions on this subject.

knez wrote:

Otis wrote:

That's multiple implementation inheritance, and that's not supported in .NET.

I know, so I didn't post code that does multiple inheritance. In the example I posted, it seems to me that everything leads to mixing region usage in templates and "custom" inheritance. I wanted to get other opinions on this subject.

Ok, to be sure I understand your point: what you suggest is that the code generation cycle should support multiple TYPE inheritance and where possible should help implementing interfaces by generating code already? (stubbing out code etc.) ?

Otis wrote:

Ok, to be sure I understand your point: what you suggest is that the code generation cycle should support multiple TYPE inheritance and where possible should help implementing interfaces by generating code already? (stubbing out code etc.) ?

No, I really wanted to get opinions, I didn't want to suggest anything.

knez wrote:

Otis wrote:

Ok, to be sure I understand your point: what you suggest is that the code generation cycle should support multiple TYPE inheritance and where possible should help implementing interfaces by generating code already? (stubbing out code etc.) ?

No, I really wanted to get opinions, I didn't want to suggest anything.

Ok Though you gave me a great idea to solve one of the major painpoints of the moment: adding custom code to the generated code: the developer should be able to select additional assemblies which contain types and which should be referenced/implemented by an entity for example.

Looking at your example, it's clear there can be only one parent class and the other one has to be aggregated inside that class, wrapped with implementations of its interface (the general way of implementing MI in .NET / Java)

Persistence of those classes can be difficult. The code generator can solve this problem in a way, but I'm unsure if that leads to maintainable code. With maintainable code I mean: if you come back after a year, start LLBLGen pro, and want to change something in the model, will the code you wrote be runnable still, and will the generated code update the existing code or will it require a different setup? The more dependencies are added, the less maintainable the code will become.