I'm designing application with three-tier model (UI-server-DB) application, which includes 8 to 10 features. The application uses the following model: - The database and business logic will be in a .net based server application and UI will be in a WPF application. The communication between WPF UI app and Server app will be using WCF services.

Basically I'm looking for design ideas for the Data Access Layer which will be in the server application using ORM library from LLBLGen Pro.

Approach 1:

•Create a common database class library in the server application which includes the all the entity classes and datamapping classes. Individual features will reference this common class library

Approach 2:

•Create individual db class library for each of the feature service ( 8 to 9 services) and entity classes and datamapping classes will be in this library. So individual feature is more modular and less depends on other features in the application.

So looking for the modularity, scalability and maintainability of the application, what would be a good design approach??

This has been asked several times before. Search the ARchitecture forum for: Modular, or modules.

Here is one of these threads: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=15063

You can make use of v.3.x Grouping feature. Please check the Designer Documentation for "Group Element" & "Group Usage"

Hi Walaa, Thanks for your quick response and pointing out the related discussion thread.

I liked one of the comment in that is to seperate the project per module/group (feature). However is there any way to address the related entites scenario? Or recommeded way is to reduce the dependancy between features?

If you want separation of entities, I'd suggest you create a project per group/module. Note that doing this you loose the ability to explicity relate entities between modules/projects.

Which version of LLBLGen are you using?

Right now we are using v2.6 and planning to migrate to v3.1 soon.

If you want project per group, that is only available in v3.x (see this). And yes, if you choose to generate a project per group, you loose ability to relate objects between groups: otherwise you are tied to always reference other assemblies (those from other groups) in your generated code (coupling and cohesion). So, it's your call.