We are evaluating LLBLGen Pro 2.5 as the ORM solution for an enterprise wide application framework.

In our environment, we have a team that builds a common layer which will contain entities that subsequent teams will extend or use as properties of their own custom entities.

For example:

Single Sql Server 2005 Database with the following hierarchy
- Person (supertype)
      - Employee (subtype of Person)
             - Manager (subtype of Employee)
- Department

Employees LLBLGen Project (target-per-entity inheritance)
- PersonEntity (supertype)
         - n:1 relationship with DepartmentEntity
         - EmployeeEntity (subtype)
- DepartmentEntity
         - 1:n relationship with PersonEntity

Employee Service Visual Studio Project
- References EmployeesGeneric and EmployeesSpecific assemblies generated by LLBLGen Pro

Managers LLBLGen Project (target-per-entity inheritance)
- ManagerEntity (subtype of EmployeeEntity)
      - Has a collection of EmployeeEntities

Manager Service Visual Studio Project
- Refs Employees Generic/Specific assemblies to provide PersonEntity & EmployeeEntity
- Refs Manager Generic/Specific assemblies to provide ManagerEntity

Question #1: Can entities defined in one LLBLGen project be extended by entities defined in a higher layer LLBLGen project?

Question #2 Can entities defined in one LLBLGen project be used as properties for an entity defined in a higher layer LLBLGen project?

Thanks.

Yes to both questions.

Also maybe you'd like to check the Manager Templates, and / or the 2 class scenario templates.

Thanks for the response.

Also maybe you'd like to check the Manager Templates

Does that mean I should look at the ManagerEntity properties in the LLBLGen Pro designer? Or does Manager Templates refer to something else?

Manager Templates can be found in the v.2.0 3rd party downloads section.

More info: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=11308

How to I access the 3rd party downloads section? I do not have a customer id / password. We have not purchased LLBLGen Pro yet. We're still evaluating.

Sorry, but these are only available for customers.

The manager templates are more of a utility library, I don't think they're necessary in this case. I'll address your questions in detail below.

copperpot wrote:

We are evaluating LLBLGen Pro 2.5 as the ORM solution for an enterprise wide application framework.

In our environment, we have a team that builds a common layer which will contain entities that subsequent teams will extend or use as properties of their own custom entities.

For example:

Single Sql Server 2005 Database with the following hierarchy
- Person (supertype)
      - Employee (subtype of Person)
             - Manager (subtype of Employee)
- Department

Employees LLBLGen Project (target-per-entity inheritance)
- PersonEntity (supertype)
         - n:1 relationship with DepartmentEntity
         - EmployeeEntity (subtype)
- DepartmentEntity
         - 1:n relationship with PersonEntity

Employee Service Visual Studio Project
- References EmployeesGeneric and EmployeesSpecific assemblies generated by LLBLGen Pro

Managers LLBLGen Project (target-per-entity inheritance)
- ManagerEntity (subtype of EmployeeEntity)
      - Has a collection of EmployeeEntities

Manager Service Visual Studio Project
- Refs Employees Generic/Specific assemblies to provide PersonEntity & EmployeeEntity
- Refs Manager Generic/Specific assemblies to provide ManagerEntity

Keep in mind that creating parallel hierarchies isn't really helpful. With parallel hierarchies I mean the following:

If I have CustomerEntity which has a collection of OrderEntity instances as it has a 1:n relation with orderEntity, and I then create a MyCustomerEntity class that derives from CustomerEntity, that MyCustomerEntity still has a reference to a collection of OrderEntity. If I then also create a subtype of OrderEntity, MyOrderEntity, and create a reference to such a collection in MyCustomerEntity, I have a parallel hierarchy: Customer <- Order vs. MyCustomer <- MyOrder.

So I'm not entirely sure what you mean by "will contain entities that subsequent teams will extend or use as properties of their own custom entities."

If you want to create classes which aggregate entities, no problem. If you want to create new entities, map them to a database table/view or hierarchy of tables/views and you add a property to that class which refers to a different entity, and that property isn't mapped onto a relation, it gets complicated because that related entity isn't usable in hierarchy fetches of graphs, joins etc. : it's a class reference, not an entity relation.

Question #1: Can entities defined in one LLBLGen project be extended by entities defined in a higher layer LLBLGen project?

What do you mean exactly with extended ?

Question #2 Can entities defined in one LLBLGen project be used as properties for an entity defined in a higher layer LLBLGen project? Thanks.

You can always add a property, but it's not the same as having that property be mapped onto a relation.

To get back to your example, you should keep your hierarchies in the same project. The thing is that you can't mix them together, as they don't know eachother if they're not in the same project. So your manager in the managers project has a relation with employee. Though which one? The one in his project or in the Employees project?

So to solve this complexity, keep things together which relate to eachother. If you have separate sub domains in your domain, or subdomains which are related through non-inheritance entities, you could think of cutting the projects up in separate ones, with each one containing a subdomain and map the two entities which connect them twice: in each project the entity exists.

Of course, it doesn't really matter if you don't exchange entities between projects. After all, they all target the same database. So if a subsystem for managers works with a different set of entity definitions as another project, that's completely OK, the thing is that if you want to refer to 'EmployeeEntity' in a common layer, which one is that? The one in the employees project or the one in the managers project?

Thanks for your response. It was very helpful.

Question #1: Can entities defined in one LLBLGen project be extended by entities defined in a higher layer LLBLGen project?

What do you mean exactly with extended ?

I mean create a subtype of the lower layer entity, add new attributes to it and have it be available for persistence. The supertype should be the type from the lower layer, not the layer containing the subtype.

To get back to your example, you should keep your hierarchies in the same project. The thing is that you can't mix them together, as they don't know eachother if they're not in the same project.

Understood

Of course, it doesn't really matter if you don't exchange entities between projects. After all, they all target the same database. So if a subsystem for managers works with a different set of entity definitions as another project, that's completely OK

Interesting point. We'll have to think about any un-intended consequences this may (or may not) have on our system.

copperpot wrote:

Thanks for your response. It was very helpful.

Question #1: Can entities defined in one LLBLGen project be extended by entities defined in a higher layer LLBLGen project?

What do you mean exactly with extended ?

I mean create a subtype of the lower layer entity, add new attributes to it and have it be available for persistence. The supertype should be the type from the lower layer, not the layer containing the subtype.

That's not supported at the moment. LLBLGen Pro reverse engineers the entity model to the level of NIAM/ORM from the table schema + views. This means that you can't, in code, define new entities and map them as subtypes of existing entities, in code, or add attributes and have them persisted: the entity model is altered in the designer, you produce new code from it and then you work with that model.

You can create DIFFERENT models from the same schema, one which is simple and has for example Person and Employee as that's enough for the application it's required in. Another model (== another llblgen pro project altogether) contains Person, Employee and Manager. Code-wise the CLASSES are different. So you have a different Person and Employee entity class in that second project.

This might sound cumbersome, but it's actually the world upside-down: as the entire entity model is as it's materialized in tables and views, you should create that model in code once. Then in the various applications you should use the subset you need. So if in one application Person and Employee are good enough, use them and ignore Manager.

This gives the clearest way of how things are mapped: that's defined once. Using dependency injection with validators etc., you can change behavior per application if you wish.

If an application is to be used separately, you can create a different entity model in a separate project. You can share validators, authorizers etc between projects, as those are classes separated from the entity code.

However, if you want to have a core entity class library and extend it with classes and add properties and map them using different mapping files in different projects, this isn't supported.