0

We are working on suite of applications in our company. Each applications have different business logic but share some structures. For example one application is for "IT services" and another one is for "package handling system" among different buildings of the company. We want to create each application with separate asp.net mvc projects (Entity framework Code-First). But the problem is that all of the applications have some similar entities. For example all of them have People, Buildings and Floors Entities in their dbContext. and also have some other tables that have relations to this similar tables What is the best approach to designing this applications?

  1. Create a single database for all of the applications? what is side-effects?
  2. Create separate Database for each application and duplicate the similar Tables? (currently we working on this but we should write some SQL server jobs to always sync this tables. so I don't think its a good approach)
  3. Create a database for shared tables and another databases for each application. This will cause to lose relations between tables and also produces multi-Context applications (I prefer this but I read that with Code-First EF and linq, it is not possible to query cross multiple contexts)
  4. or something else ?
iamnapo
  • 52
  • 7
  • What you're doing is asking someone else to do the hard work for you. What have you tried already ? Can you give the answers to your own questions ? also if the code shares entities, you could just make a separate project, compile it to a .dll and share it between projects. – Stralos Feb 09 '17 at 15:24
  • 1
    Are the `People`, `Buildings`, and `Floors` all actually the same data? i.e. could a row in `ITServices.People` refer to the same person as in `PackageHandling.People`? If so, I don't see how #2 is a reasonable approach. Also, your #3 solution could have referential integrity and wouldn't require multiple contexts if your database system supports synonyms. It would be functionally very similar to #1 in that case. And you'll need to work out a proper locking mechanism on the shared tables. – stephen.vakil Feb 09 '17 at 16:52
  • thanks @setphen.vakil. I'm working on synonyms idea – iamnapo Feb 14 '17 at 14:20
  • 1
    4. It sounds like you *might* benefit from microservices ... i.e., one or more (preferably more) web services accessible only inside your organization. Each microservice knows how to handle data (related tables) for a single slice of all possible features. In this architecture, data access happens in a single application -- the web service. You expose an end point that each MVC app consumes. – Bob Tabor Feb 23 '17 at 01:07

1 Answers1

0

I am very interesting for Db management system. I like your 3 aproach firstly. All of them different advantages and disadvantages. If you have huge datas on this db may you can use seperate Database like solution like 2. But you have to develop sync mechanism that you said. If we look at another advantge of seperate db that when one db is failed or broken, another db can work :) but some of departmant data can be unavaible until error fixed. This can be good for huge systems.

Lastyly, "Create a database for shared tables and another databases for each application ", this idea is so good :)

May you can use N-Tier artitecture at least 3 tier(Business-Presentation-Data)and

Busines==> Your Worker Functions

Data Layer==> Many Db Context

Presentation ==> MVC project

I think the solution 3 and Lose Coupling Connection with N-Tier Artch is best way.

Lastly may you seach; Unit Of work, Ninject Freamwork, N-Tier topics

Note: Alwasy the code-first :) I like Code First style to much :D

Have a nice day :)

If you want I can show a few N-Tier structure Lesson Link around "CodeProject.com" and Stackoverflow

Eyup Can ARSLAN
  • 692
  • 9
  • 25