Hi there,

I'm a little dissapointed that entities cannot be associated if they're in different groups _and _the groups are exported as seperate projects.

I would like to be able to have, say, a core domain project and then a sub-domain project that references the core domain project. In the sub-domain would be entities that inherit from the core domain classes.

At the moment it seems as though everything would have to be in the same project which reduces some of the granularity of the design.

Cheers, Ian.

What's the point of generating entities into different projects and yet let them reference each other (cross projects). Which means no project would ever be used alone, and always will need to reference each other? Wouldn't one project/assembly be ideal in this case?

Don't separate into different assemblies unless you can reuse these assemblies independant of each other.

Which means no project would ever be used alone, and always will need to reference each other?

Not necessarily. One could use the core alone or perhaps plug in a different sub-domain.

And even if one was only ever going to use the two projects together, it makes thing easier to understand if different layers of the application are sectioned into different projects. When working on the core you know there's no chance of the sub-domain complicating things because there's not even a reference to the sub-domain's types.

I think the same argument that you're making could be leveled at the LLBLGen designer's group feature.

The idea is that an entity is saveable in project (group) X and used as read-only in group Y. So e.g. you have 'Product' in your product group, and you also want to use it in a different group, e.g. CustomerOrderGroup. In that Customerordergroup, create again the Product entity, map it to the same table and assign the relationships you want it to have in the CustomerOrdergroup.

This way, you can obtain the same entity instances from the DB in both projects, and save them if you wish, though it's likely you'll use the Product group project as the one which persists the products as well.

Bit of redundancy there isn't there having the same entity appear in multiple projects?

A bit, yes, but as long as it's a simple entity mapped directly to a table, the overhead in managing it isn't huge.

Matt

Ian wrote:

Bit of redundancy there isn't there having the same entity appear in multiple projects?

It's not done that way because it might be the entity has relationships with entities which aren't in the other group.

'Employee' has relationship with Order, in the OrderManagement group. In the HRM group, there's no 'Order', so it can't have the relationship. You simply create a new entity 'Employee', mapped onto the same target. You can have less fields in that Employee if you want (or more, if you use 'Employee' in the OrderManagement group as readonly) and different relationships, which are only shown as FK fields in other groups. Re-using the same entity would actually make things impossible to use.

These additional mappings of an entity sound like views. Couldn't you have both?

i.e. Employee references Order in OrderManagement as well as there being a view of Employee in HRM.

Ian wrote:

These additional mappings of an entity sound like views. Couldn't you have both?

i.e. Employee references Order in OrderManagement as well as there being a view of Employee in HRM.

Doesn't have to be. Through fk fields, you can persist employee in both. Having it 'automatic', makes things complicated because employee is not in OrderManagement. So the reference from Order to Employee... what should be done with that? Placing employee in OrderManagement? Or ignore the relationship? If you say, 'place it in OrderManagement', what to do with Employee m:1 Department (which is in HRM) ?

So by explicitly defining the entity multiple times, you are in control what to do. It's easy to do though, simply reverse engineer the entity again into the group you want the duplicate in.

Yes I think I see. These bi-directional relationships can't exists if the enities are in different projects.

However, what about inheritance relationships? Person could be in one group and a sub-type Employee in another. In this case Person wouldn't need a reference to Employee.

We didn't allow that as it would create a dependency which could lead to a circular dependency. The models / projects should be seen as independent of eachother.