Home/ Questions/Q 6110461
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T14:31:06+00:00

I am battling with dealing with how best to break a domain model up

  • 0

I am battling with dealing with how best to break a domain model up across multiple Visual Studio projects. I am working with EntityFramework 4 and Enterprise-type patterns to rationalise a system which can be reused for various applications. Eventually I want to end up with a set of mix-and-match DLL class libraries which can be reused across web applications.

Sor far, I have a standard database schema which encompasses user information, a basic CRM, basic CMS and also a lightweight eCommerce platform.

The CRM / user tables are the core of the system. The CMS and eCommerce platforms utilise the CRM user tables. I want to define a core domain model from which the CMS and eCommerce domain models link/derive from.

So far, I have three visual studio projects:

  • MyNamespace.Model.Core
  • MyNamespace.Model.CMS
  • MyNamespace.Model.Commerce

In each of these models is an Entity Framework Domain Model EDMX file. The EDMX contains all of the relevant tables for each. This means that the EDMX file for the CMS and Commerce projects contain some of the user tables. I could in theory have one big EF model and put all the POCOs in one class, but this isn’t very extensible.

The projects also contain POCOs for each of the tables (these should probably be in a separate project but until things are sorted, they can stay where they are!).

When I come to use the domain model in a service layer with a Unit of Work, I only want to use one ObjectContext (this is actually an IObjectContext wrapper that targets the EF ObjectContext). For this reason, I have given each of the EDMX files the same Entity Container Name and namespace.

Questions:

  1. Is this the correct thing to do?
  2. If there are EF models in the same namespace with the same container name (albeit across different projects) will this cause problems if a table/entity is repeated (e.g. customers) in these different models?
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Well EF is very new and still almost everyone like you are experimenting and finding new ways to create better systems. So there will not be any straight forward answer but I can put my thoughts and my problems I have faced already.

    Problems with multiple EDMX

    1. Sharing entities to build more generic logic will be difficult as you will end up having same named entities in multiple context.
    2. If they are going to be stored in one database, then in future you might need joins and relationships between two entities that are in different context.
    3. Writing reflection based generic logic will not be possible.
    4. Unit of work across multiple context will be complicated.
    5. EF already implements unit of work and RIA Services on top of it will be a good candidate instead of reimplementing whole thing.
    6. Keeping everything in one context will allow you to build extensible application. And mostly all the code will be auto generated so it will not make much of difference.
    7. We did try this and we realized that later on it needed lot of glue code and things became dirty as repetation of code and reports became big trouble and we finally moved everything in one context.

    If I am going to store everything in one database, I see it as just one repository.

    • 0