Hi!

I wonder if there is a way to classify EntityClasses through one LLBLGen Pro (1.2005.1) project? (i.e. I would like to put CustomerEntity to [DBGeneric].Customers.dll and ProductEntity to [DBGeneric].Products.dll)

Thanks.

  Vladimir

I would do that by manually creating different projects for classifying the entity classes. All use the same namespace [...DBGeneric...]

I think I know the answer to this one, but nevertheless...

In given Documentation inheritance example, can code be generated that CompanyCarEntity and it's sub-types are placed in DBGeneric.EntityClasses.Cars.dll and EmployeeEntity and it's sub-types in DBGeneric.EntityClasses.Employees.dll assemblies?

Vladimir

No. The reason for that is that it's very hard to get separate assemblies, because you can't have loops in assembly references. So if CompanyCar references Boardmember, boardmember has to be in the same assembly as companycar. Now, employee can only be in another assembly, if no class references companycar or any other type in the other assembly. This is highly unlikely because in a normal relational model, everything is related to eachother in 1 big connected graph.

The fact that there's just one relational graph should not impose restrictions on the OO model. We weren't planning on having assembly cross-references, far from that! When you design a large-scale system, you always want to group high-cohesive objects in a logical package. The fact that some of those objects are persistent should not break the system design, right?

For example, in our system we can have, to depict some, ApplicationUser, Demographics, and BusinessDomain packages. Each of those, as you can imagine, contains some persistent objects. The system is modeled in such a way that the ApplicationUser package is dependent upon Demographics package (not vice-versa) and that BusinessDomain package depends upon ApplicationUser and Demographics (not vice-versa). Likewise, ApplicationUser database table references Person table (not vice-versa), and Employee table (BusinessDomain) references Person table (not vice-versa) Now, BusinessDomain package is application-specific, but the other two should be reusable - we could easily have another application with application users. And it's not just that, think of all client packages that have to look at one big public interface of one package, and all the things that you actually want to hide - it becomes very difficult to design anything upstream...

So, it would be great if LLBL would provide the means to decompose this big relational graph and allow for the logical separation in the OO realm. Without that, we can never have clean design.

I hope that you understand our need.

knez wrote:

The fact that there's just one relational graph should not impose restrictions on the OO model. We weren't planning on having assembly cross-references, far from that! When you design a large-scale system, you always want to group high-cohesive objects in a logical package. The fact that some of those objects are persistent should not break the system design, right?

I agree. Though in practise it's hard to accomplish that if you have a set of entities which are all related (directly or indirectly).

For example, in our system we can have, to depict some, ApplicationUser, Demographics, and BusinessDomain packages. Each of those, as you can imagine, contains some persistent objects. The system is modeled in such a way that the ApplicationUser package is dependent upon Demographics package (not vice-versa) and that BusinessDomain package depends upon ApplicationUser and Demographics (not vice-versa). Likewise, ApplicationUser database table references Person table (not vice-versa), and Employee table (BusinessDomain) references Person table (not vice-versa) Now, BusinessDomain package is application-specific, but the other two should be reusable - we could easily have another application with application users. And it's not just that, think of all client packages that have to look at one big public interface of one package, and all the things that you actually want to hide - it becomes very difficult to design anything upstream...

So, it would be great if LLBL would provide the means to decompose this big relational graph and allow for the logical separation in the OO realm. Without that, we can never have clean design.

I understand. Now, to move into the practical side of things to get things realized -> if you define different subsets of entities while generating code, for example the application entities, the demographics entities and the business domain entities, does that work for you or not (just to see if that's the direction you want us to go).

The problem is that if ApplicationUser has a relation with an entity in teh BusinessDomain package, it can only be done if that relation is generated as if the ApplicationUser has a relation with an interface which is implemented in the BusinessDomain package but is define in a generic package. Interfaces can solve this in one way, the disadvantage is a lot of casting.

The ability to categorize / group entities into modules / packages must be my nr #1 missing feature.

I requested this feature in the past in this thread: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=3527

I agree with knez, when designing a large database-driven system I typically tend to categorize my objects into a particular 'namespace', 'module', 'sub-system' or 'package', whatever you like to call it. Such packages can be for example called 'Shop', 'Crm', 'Hrm', 'Mailing' etc etc. Thing is, each system could contain one ore more of the packages in the same database. In my case, each table has a prefix with the package name. Each package could in theory contain an object called 'Person'. That's why categorizing in LLBLGen would be very handy.

In my current project I solve this particular problem by using a seperate LLBLGen project for each package in my project. I'm using adapter so I end up with a seperate data adapter for each package.

It would be great if we could do something like this: CrmPerson = New Categories.Crm.EntityClasses.Person HrmPerson = New Categories.Hrm.EntityClasses.Person

or

CrmPerson = New EntityClasses.Crm.Person HrmPerson = New EntityClasses.Hrm.Person

In the designer you could display the entities with the category name in front in the following syntax: <CategoryName>.<EntityName>

I understand that such a feature could be hard to implement. I really would like to hear from others how they solve this issue. Particularly when your DB contains +100 tables. How do you name your tables / entities? How do you setup your DAL? Or maybe you use a different database / schema for each package? Any ideas on best practices regarding this issue?

Maybe a feature for v2? Thanks in advance!

Thanks for the feedback, Dennis

Categorizing the entities isn't the hard part, it's a designer thing and not really a problem. The hard part is in the fact when the user wants to generate a VS.NET project per category and there are bi-directional relations with other categories (entity X in category A references entity Y in category B and Y references Z in A)

Its often not solveable for obvious reasons. Ok, with interfaces it can be done, but interfaces give different problems, especially in the typed members department.

Another way to solve this in the future might be to have different llblgen pro projects, like A, B and C, and when you work on B, you can define one-way relations with A or C and elements in A or C and generate code with that, which requires that the generated code references A or C.

This at first looks like a killer feature, but it also brings a huge problem as well: maintainability. Changing a referenced field in C, might cause problems when generating B again, or compiling B...