Лучше ли разделить программное обеспечение на несколько модулей, каждый из которых имеет свою базу данных

Question

Я работаю над приложением для здравоохранения, разработанным в основном на asp.net с Oracle 11g в качестве бэкэнда. В своем текущем состоянии приложение разделено на 3 уровня: пользовательский интерфейс, BLL и DAL. Поскольку BLL и DAL являются проектами библиотек классов, они развернуты как одна DLL (одна DLL для BLL, а другая для DAL). Недавно программное обеспечение было рассмотрено другим разработчиком, предложившим разделить все программное обеспечение на отдельные модули, каждый из которых имеет свои собственные проекты и базу данных, т.е. модуль инвентаризации, например InventoryUI (проект веб-приложения asp.net, InventoryBLL (проект библиотеки классов) и InventoryDAL(Проект библиотеки классов). Все модули получают три разных проекта с отдельной базой данных, взаимодействующей друг с другом через веб-сервисы.

Так что мои вопросы

1. Эта предложенная архитектура лучше, чем у нас?
2. Лучше иметь более одного dll для BLL и DAL. Каковы плюсы и минусы.
3. Лучше иметь более одной базы данных для одного приложения? Как?

Любые ссылки, предложения приветствуются.

Answer 1

Преимущества физического разделения ваших модулей в том, что они позволяют логически распределить работу между различными командами. В вашем случае у вас может быть команда инвентаризации, которая отвечает за все вещи, связанные с инвентаризацией, они публикуют API, а для всех других команд основой модуля инвентаризации является черный ящик. Это является преимуществом для решения проблемы сложности вашего домена.

Недостатком является то, что если ваш проект небольшой, вы можете значительно усложнить процесс разработки и развертывания программного обеспечения, особенно если вы делаете что-то вроде преодоления барьеров процесса (или машины).

1. Предлагаемая архитектура может быть лучше в зависимости от потребностей проекта, особенно в отношении размера. Некоторый компромисс также может быть лучшим подходом - если вы обнаружите, что у вас может быть несколько десятков или сотен модулей, объединение схожих модулей - это практический подход.

2. Можно использовать несколько библиотек DLL для бизнес-логики и доступа к данным, если есть общий предок, который предоставляет базовые классы для рисования. Каждый DAL, имеющий свою собственную конфигурацию в отношении строк подключения, является очень плохим местом. Аналогично, если один DAL использует шаблон сопоставления, а другой использует активную запись - хотя оба шаблона могут сосуществовать - эти шаблоны должны быть предоставлены в базовых классах.

3. Предполагая, что ваша СУБД поддерживает несколько схем, я бы сначала использовал несколько схем, прежде чем переходить к нескольким базам данных. Я обращаюсь к нескольким базам данных, когда меняется характер базы данных - большой объем транзакций или большой объем чтения (аналитика). Если у вас есть транзакции, которые должны проходить через модули, и вы физически разделили базы данных, управление этими транзакциями может оказаться излишне сложным.

Answer 2

Работая над проектом, который (по необходимости требований клиента) унаследовал вторую базу данных путем включения другого приложения, я бы не стал пропагандировать этот путь. Это делает кодовую базу запутанной, и вам часто приходится дублировать данные между базами данных или использовать бизнес-логику для доступа к обеим базам данных (напрямую или через какой-либо другой механизм, такой как вызовы веб-служб). В рассматриваемом случае это было необходимо, поскольку одна база данных была Oracle, а другая SQL Server, поэтому объединение двух хранилищ данных было бы значительной головной болью, но я бы не выбрал путь, который я выбрал бы легко.

Какие аргументы выдвинул рецензент, который предлагал разделить на несколько проектов с отдельными базами данных? Даже если вы хотите разделить бизнес-логику на отдельные библиотеки DLL по функциональным областям, зачем нужны разные базы данных и DAL? Это похоже на усложнение ради сложности, если только ваша кодовая база не является поистине гигантской, ИЛИ объем хранимых данных вызывает проблемы с производительностью в одной БД, которые могут быть уменьшены путем разделения данных на отдельные БД. Учитывая объем работы, который может быть вовлечен в это изменение, похоже, что этот парень должен доказать, почему вы должны это делать!

Answer 3

Это полностью зависит от ваших бизнес-требований.

Похоже, рецензент указывал в сторону SOA. Разделение на изолированные физические модули дает некоторую безопасность, потому что части системы могут выйти из строя, не останавливая все.

Однако разделение приложения также усложняет продукт (особенно в сценариях, когда для совершения одной бизнес-транзакции необходимо взаимодействовать с несколькими модулями).

Answer 4

Я склоняюсь к тому, чтобы сначала определить поддомен и убедиться, что они логически разделены на основе функциональности; не слишком большой, не слишком маленький. Каждый поддомен затем станет изолированной частью программного обеспечения, которая состоит из уровня обслуживания, уровня приложений, уровня домена и уровня инфраструктуры (как я описал здесь).

Это также означает, что у каждого из них есть свои собственные репозитории, но не обязательно отдельная база данных. На самом деле, я в основном хочу сохранить одну базу данных, но использовать разные схемы для определения домена, к которому принадлежат таблицы. Таким образом, вы можете сохранить ограничения между таблицами (перекрестная схема) и гарантировать согласованность данных.

Поэтому я думаю, что имеет смысл структурировать ваш код в логических модулях (и на самом деле вы должны это сделать), но я бы не стал делать это с базой данных, если это действительно не нужно, потому что это усложнит вашу жизнь с точки зрения обслуживания и надежность.

Answer 5

Все зависит от вашего требования.

Если вам необходимо перейти к отдельным физическим уровням в будущем, это может пригодиться (вы можете запустить каждый проект на разных машинах, разделяя каждый модуль). Однако это приведет к снижению общей производительности приложения. Преимущества, которые это может принести, состоят в том, что другие проекты могут получать доступ к этим отдельным проектам / уровням независимо.

Я очень скептически отношусь к тому, что вы могли бы получить какую-либо выгоду от разделения баз данных. Планируете ли вы в будущем перенести каждую базу данных в отдельную коробку? Если нет, то я бы сказал, придерживаться одной базы данных с различными схемами.