I would like some opinions on the following idea, and how I can achieve my desired results with LLBL.

We have a large main database which has many different areas or domains (set of tables). The domains are mainly broken up into a single central core domain and many feature domains. The core domain contains data required by all (or most) features of our product. The feature domains contain data for those features. The entities in the feature domains are related to the core domain entities, but not usually related to other feature entities.

For example if the core contains user and product data (maybe tables like User, Address, Product, Supplier ...) then some of our feature domains might be Authentication (with tables of data for authenticating a user), Orders (with tables relating users and products), User Shipping, Inventory...

That's a bit of a contrived example, but I think it shows where I'm going.

As we're developing the above, we would create the core data structures and develop our DAL for it. I want to use a component architecture, so from their I want to create business logic components that are largely independant (or loosely coupled if required). Each BL component maps to a feature domain in the database. And I would like each BL component to have its own DAL. These will likely need to use the core DAL, but since they are the only business level objects that know about their data, the DAL for their data isn't (and shouldn't be) included in the core DAL. This way we can neatly package everything from the DAL up to the UI in one feature component. Not only does this make deployment and testing easier, it reduces the risk that someone will stick authentication code into an ordering component.

So going back to the example, I would like to create Data Access Layers (DALs) for the core user and product data. And then as we add our features a new DAL assemblies for Authentication, Orders....

Now to the trouble, relationships. Is it possible to do this with LLBL? Obviously if I add tables for authenticating a user, their going to be related to the user table in the core domain. Likewise with all of the other feature domains, they'll have data relationships to the core (and maybe other features). That means I need to regenerate my core DAL with each new feature. But is there a way that I can add the required relationships to the LLBL generated entities, without having thoses entities included in the assembly? So, can I include a relation between two entities where one is in my core DAL assembly and the other in my feature's DAL assembly?

Ideas? Is this good, bad, ugly?

Thanks Chris

the problem with your setup is that you can have 2 assemblies, A and B, which have a cyclic reference to eachother: A has an entity E which has a relation with entity F in B and vice versa (as relations are 2-way: customer has a relation with order, and order has a relation with customer). So to be able to compile A you need B and vice versa, that's not going to work.

You can create EntityRelation objects in code, if you want to, when filtering on A.E when you're fetching B.F for example, or vice versa, in code which references both A and B. Though code in E and F which produces the related entity (or a collection of them), like E.F or F.E, isn't possible, for the reasons I explained above.

Your problem is typical to a problem also plagueing SOA: where to draw the line what is located in service A and what is located in service B? Extreme example: you have a customer service and an order service, which can work OK, though what about when you want to get from the customer service all customers which have placed an order in a given month? That's a problem, because you in theory should consult the order service, but that's very inefficient, as a simple query would work as well, BUT that would mean the customer service could touch the order entities (and vice versa).

I was thinking a bit in separated BL tiers with a uniform DAL, and divide the functionality in the BL tiers, but you then run into the same problem as I described above with the SOA example.

You can of course select a group of entities, generate code for them, then select another group of entities, generate code for them too, but I don't think that's maintainable.