Hello,

I'm in charge of designing the architecture of a new mission critical platform for a client, in a medical environment. Due to the nature of the medical data, we are obliged to be FDA CFR 21 compliant, which means an enormous amount of paperwork and validation for every new deployment. So even the smallest bugfix leads to a big load of work and headaches in terms of deployment and testing.

Now, the new platform will consist of multiple applications, ranging from administrative (client/server) apps to webapps and WCF services exposed to clients, all accessing the same data (or subsets). There is a strong preference to keep all data into 1 database (possibly in different schema's)

I was thinking of going in this direction : Suppose the first 2 apps in the platform are ApplicationA and ApplicationB. Since ApplicationA is an administrative, internally-used app, I'm going to choose a simple architecture: client/server WPF app. No need for WCF services and the overhead of having to create DTO's etc (YAGNI principle). Of course the requirement is that when ApplicationB is created, we want to prevent a redeployment of ApplicationA (which would be the case is ApplicationA and ApplicationB shared the same generated DAL DLL)

For this reason, the proposal concerning the database and usage of LLBLGen is a follows: First of all, use multiple schema's in SQLServer. In our case, a "schemaCore" for general entities (eg. Users & roles), a "SchemaA" for ApplicationA, a "SchemaB", for the extra entities used in ApplicationB. Important is that ApplicationB will also use entities from schemaA, but not vice versa. For the development of ApplicationA, I would generate a DAL with only the entities of SchemaCore and SchemaA. Later on, when developing ApplicationB, we would generate a new DAL with entities of schemaCore, SchemaA and SchemaB. This way, when SchemaB changes, only ApplicationB needs to be rebuild, validated and deployed. Of course, when SchemaCore or SchemaA changes, everythings needs to be rebuild.

The problem is see with this approach is with shared business logic. Suppose that ApplicationA has some business rules that we also need in AplicationB. If we directly use the generated entities, this business logic needs to be copy-pasted and recompiled in ApplicationB to use its entities instead of ApplicationA's entities. A possible solution is abstraction through interfaces. I would create a dll with the interfaces per schema, and share these among the different applications. So in the end I'll have : - ApplicationA that uses a LLBLGen generated DAL accessing schemaCore and schemaA. The business logic in applicationA uses interfaces from schemaCore.Interfaces.Dll and schemaA.Interfaces.Dll - ApplicationB that uses a different LLBLGen generated DAL accessing schemaCore, schemaA and schemaB. The business logic in applicationB uses interfaces from schemaCore.Interfaces.Dll, schemaA.Interfaces.Dll and schemaB.Interfaces.dll

The key factor in this design are the interfaces per schema that can be shared among the applications. So now my question, can LLBLGen generated such interfaces ? Ie. if a UserEntity has fields 'name' and 'firstname', LLBLgen would generate an interface IUser that has properties 'name' and 'firstname'.

Is this clearly explained and does it all make sense ? Am I overlooking something obvious or has anyone allready done something similar ? Worth noting is that I'll have to make heavy use of auditing and would like to reuse as much components as possible over the different applications.

Thnx for any answers or advice !

Since you know in advance you are going to have WCF services, webapps, and WPFs application. Some of them will share business logic and parts of the schema, so why don't you just maintain one code base (DAL & BL) in a service which serves all possible clients.

If not in a service, then at least in one or more code assemblies that's shared between different implementations.

Well, the ERD is finalized for the first application (the WPF app) but it will extend once work begins on the next apps. When the DB is extended with new tables, I don't want to have to redeploy the first application. (so it has to have it's own generated dal with the correct subset of tables) Working with services gives also a lot more overhead and work. For the time to market for the first application, the most simple thing is a 2-tier wpf app.

Walaa wrote:

If not in a service, then at least in one or more code assemblies that's shared between different implementations.

That was exacly my question Since the DAL is generated for the correct schema's per application, I cannot share that one. But if I could generate entity-interfaces per schema, I could share these ...

HcD wrote:

Well, the ERD is finalized for the first application (the WPF app) but it will extend once work begins on the next apps. When the DB is extended with new tables, I don't want to have to redeploy the first application. (so it has to have it's own generated dal with the correct subset of tables) Working with services gives also a lot more overhead and work. For the time to market for the first application, the most simple thing is a 2-tier wpf app.

Is a trade-off situation. No one but your analysts know what would be the best approach . I'm right now in a similar scenario -maybe less complex- and I'm not going to create the service layer yet because it would create some overhead in the design/development, and for now the re-deployment is not a big issue for me. But at some point I will have to consider it.

HcD wrote:

Walaa wrote:

If not in a service, then at least in one or more code assemblies that's shared between different implementations.

That was exacly my question Since the DAL is generated for the correct schema's per application, I cannot share that one. But if I could generate entity-interfaces per schema, I could share these ...

It's not out of the box, but you can done it easily. You have to do two things:

1) Create a template that generate your interfaces. This is quite easy. Take a look at entityAdapter.template /bindings/tasks and use those as a base to generate your interfaces. See the SDK docs for more info. Let us know if you need further help on this.

2) Go to Additional Interfaces at Project Settings - Code generation info tab. And for "Entity" element define the interface I{#Name}. This will generate an additional interface for all your entities. Like:

public partial class CustomerEntity : ICustomer ...
...

This is thanks to the Attribute macro definitions v3.x feature.