Otis,

I'm looking for confirmation. Can you pls indicate if I'm looking at this correctly or not?

I have an entity called User which is the supertype of both EnergyUser - ChemicalUser - AutomotiveUser. It is a clasical example of inheritance where each of the 4 entities have their own table in the db and only user has the common columns(fields). The other 3, the subtypes, are linked to the user table on a 1:1 relation.

In the designer i can indicate the inheritance by selecting 'is subtype of' and all gets generated correctly.

As each usertype (Energy/Chemical/Automotive) has common functionality like authentication, authorisation and soforth, I've created a UserBase that contains this common functionality. I've integrated this functionality by extending the generated UserEntity (supertype) by using partial classes in the generated Llbl binairy. So far so good.

I also have an interface IUser that I created as I want other devs to be able to extend the software and I want to make sure they comply by the contract IUser. The Interfaces are combined in a seperate binairy/namespace. (Actualy, each user type has a different interface specific for its industry type where each interface has a basic interface implemented --> IChemicalUser : IUser // IEnergyUser : IUser etc)

This all results into the 2 generated Llbl binaries (I'm using the adapter model) + my binary with the interfaces and some extra binairies for typeconvertors and such.

This said, imagine creating a binairy named 'Core' (tier 1) in witch all the basic functionality for my application is defined and which uses the generated Llbl binairies. As this 'core' binairy only contains generic code, I want to place seperate binairies on top of the 'core' for different types of implementation of the software (tier 2). Eg, suppose the application would be for the chemical industry, I would deploy the core, the generated Llbl binairies, the interface binairies, any typeconvertors I need + a binairy specific for a chemical industry implementation.

In the end, this would result in a plugable frame extendable by customer developers.

The only thing I'm having problems with is this: As the application obviously is based on a db, this db would be the actual applications data repository. Ie, the database as the application needs it to run. Now suppose a customer, eg a chemical company, running my software wants to extend the use of the ChemicalUser : IChemicalUser, IUser object because they have some company specific properties/methods/events for their users and would like this incorporated into the application + this data is in a complete seperate db from the main application.

As I've done it now, I've created a second Llbl project based on sowly the customers database so it only contains data witch is customer specific. This in itself again generates the 2 Llbl binairies (again adapter) specific for this customer.

Is the above correct or does it contain any flaws? Am I making any sence? And how would I then retrieve the data from a user if the customer inherited my Core.ChemicalUser? Because of the inheritance, the Llbl framework functionality is available to the company specific inherited class, but, as it wasn't linked in the Llbl designer, I'm having doubts if I'm going about this the wrong way.

Thx Carl

PS: My apologies for the complexity of the question, but don't know any other way to explain it

PS: The reason for the seperation in datastores between the application/customer specific data is that I've found in the past that this makes it easier to maintain/release/update your own code.