mardi 13 novembre 2018

EF6 Model Separation

I am trying to have a common model referenced by multiple programs, and not sure how to design it correctly for re-use. Not all programs are going to need all parts of the model, but id prefer not to have different versions of it from a source control point of view.

I have created a (simplified) model in EF6 that incorporates the following:

Locations
Materials
Formulas

My business logic can add materials to formulas or locations:

AddMaterialToLocation(Material material)
AddMaterialToFormula(Material material)

Referencing program one needs all of the above. It has a formulations system, and a warehouse, so it wants to use both of the above functions.

Referencing program two however only has a warehouse, it doesn't need formulas. The referenced model however still does. (Program two is on a different database/PC altogether)

Of course any changes in the material or warehousing should be applied as an update to the common model, updating both programs.

I have looked at doing it the following ways: -

  1. To have the model all joined together as one, but have program two not bother to call the parts it doesn't need.
  2. To split the model in two parts. Have one half have two tables/entity classes (Locations/Materials) and the other half to have (Formulas/Materials). This allows program two to only create the part of the model it needs.
  3. Split the model in three parts, one per table/class. Have each program build up the parts individually and pass/convert between them using only basic types?
    AddMaterialToLocation(int MaterialCode, string MaterialName)

The referencing applications will both build up their own view models in the presenter anyway, so attaching the smaller pieces together after is fine.

The above solutions seem to come up with the following downsides:-


Option 1 - would end up creating lots of unused entities for program two.
Option 2 - would have two Material entites the same (which would also be the same db table)
Option 3 - would have a lot of edmx's. Nothing would be linked - id loose navigation properties etc.

Is there a better way?

Aucun commentaire:

Enregistrer un commentaire