This project has moved and is read-only. For the latest updates, please go here.


Apr 5, 2013 at 11:26 PM

I started from the Information manager sample to a POC for an modular app.

now i was just wondering where to place the entity related stuff...

Any suggestions... database is shared over 7 of the modules...

thnx Mike
Apr 7, 2013 at 7:39 PM
Edited Apr 7, 2013 at 7:42 PM
You could put the entity related stuff into the “Common” projects. All modules have access to the “Common” assemblies.

But from an architectural point of view I do not recommend this approach. If you create 7 modules then this modules should be isolated of each other. This is important because the modules should be able to evolve independently of each other. Modifications of one module should not affect another module.

Isolating the modules is not possible if they share the same entities (or the same database tables). The module separation has not only to be done on code level but on data storage level as well.

Dependent on the situation I recommend one of the following approaches:
  • If different modules have to work with the same domain objects (entities) then they should not be divided into separate modules.
  • If different modules work with the same database but use different database tables, views, etc. then every module should get its own domain objects (entities) and persistency related code. But these domain objects must not be shared between modules. Data that needs to be shared should be transferred via DTO (data transfer objects) between the modules.
Apr 8, 2013 at 8:07 AM
Thnx for the insights

The second approach matches what i had i mind. the idea is that some modules will be reusable in different apps so it clearly must be separated from the rest completely. on the other had some app can have different implementations depending on the customer where the app is deployed. e.g. contacts and contactsex...

A major requirement is that not the complete app should be rebuild when minor changes are done in one of the modules...

this way however it requires a separate context for each module...
There is still one problem and that will be the reporting module needing data from different tables across the different modules. this requires duplicate entity classes over the modules and most likely require a rebuild of the reporting module when module database changes occur...

it's acceptable to me (not ideal) but was wondering if there would be a better approach for this!?

any suggestions on this are welcome.