Лучший подход для общих объектов (таблиц) среди множества приложений

Question

Мы работаем над набором приложений в нашей компании. Каждое приложение имеет различную бизнес-логику, но имеет несколько структур. Например, одно приложение предназначено для «ИТ-услуг», а другое - для «системы обработки пакетов» среди разных зданий компании. Мы хотим создать каждое приложение с отдельными проектами asp.net mvc (Entity framework Code-First). Но проблема в том, что все приложения имеют несколько подобных объектов. Например, все они имеют People, Buildings и Floors Объекты в их dbContext. а также некоторые другие таблицы, которые имеют отношения к этим аналогичным таблицам. Каков наилучший подход к разработке этих приложений?

1. Создать единую базу данных для всех приложений? что такое побочные эффекты?
2. Создайте отдельную базу данных для каждого приложения и дублируйте аналогичные таблицы? (в настоящее время мы работаем над этим, но мы должны написать некоторые задания SQL-сервера, чтобы всегда синхронизировать эти таблицы, поэтому я не думаю, что это хороший подход)
3. Создайте базу данных для общих таблиц и других баз данных для каждого приложения. Это приведет к потере отношений между таблицами, а также созданию приложений с несколькими контурами (я предпочитаю это, но я читал, что с помощью Code-First EF и linq невозможно запросить множественные контексты)
4. или что-то еще?

Answer 1

Я очень интересен для системы управления Db. Сначала мне нравится ваш 3 aproach. Все они имеют разные преимущества и недостатки. Если у вас есть огромные данные в этом db, вы можете использовать отдельную базу данных, например, как решение, например 2. Но вам нужно разработать механизм синхронизации, который вы сказали. Если мы посмотрим на другое преимущество отдельного db, что когда один db потерпит неудачу или сломается, другой db может работать :), но некоторые из данных департамента могут быть недоступны до тех пор, пока ошибка не будет исправлена. Это может быть полезно для огромных систем.

Lastyly, «Создать базу данных для общих таблиц и баз данных, другой для каждого приложения», эта идея настолько хороша :)

Может вы можете использовать N-Tier artitecture по крайней мере, 3 уровня (бизнес-презентация-Data) и

Busines ==> Ваши функции Worker

Уровень данных ==> Многие Db Контекст

Презентация ==> проект MVC

Я думаю, что решение 3 и Lose Coupling Connection с N-Tier Artch - лучший способ.

Наконец, вы можете проследить; единицы работы, Ninject Freamwork, темы N-Tier

Примечание: Alwasy код-первый :) Мне нравится Code Первый стиль много: D

Хорошего дня :)

Если вы хочу, чтобы я мог показать несколько элементов N-Tier. Урок Link вокруг «CodeProject.com» и Stackoverflow