Создание проектов для доступа к данным, бизнес-правил и бизнес-объектов в Visual Studio

Question

Я создал решение в Visual Studio, чтобы попытаться реализовать базовое 3-уровневое приложение C#. Я исследовал эту концепцию, и теперь я пытаюсь собрать ее, используя разные проекты для каждого уровня. У меня есть проекты для DataAccess, BusinessRules и BusinessObjects.

Если проект BusinessRules содержит ссылки на проекты DataAccess и BusinessObject? (И DataAccess и BusinessObjects не должны ссылаться на BusinessRules?)

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

Answer 1

Хотя это, вероятно, не поможет с вашим вопросом, ответ всегда будет «Это зависит». Когда дело доходит до этого, нет «одного кольца, чтобы управлять ими всех». Если бы это было, архитекторов не было бы нужно.

Это, как говорится, в моем конкретном случае мне нравится:

• Есть слой доступа к данным работают на бизнес-объектах. Это предполагает, что DAL все в коде и не разделяется между кодом и хранимыми процедурами в базе данных.
• Использовать уровень бизнес-правил для бизнес-объектов. Опять же предполагает весь код, а не хранимые процедуры.
• Бизнес-правила доступа к данным - сложный вопрос. Это зависит от типа приложения и правил. Если вам нужны ваши бизнес-правила для обновления хранилища, я бы, вероятно, извлек интерфейсы из DAL, чтобы бизнес-правила могли зависеть только от интерфейсов.

Опять же, эти предметы работают в моем случае. Они могут быть совершенно неправы для вас. Кроме того, вы не указали уровень пользовательского интерфейса, уровень сервиса, уровень бла-бла и т. Д. Могут быть много частей и частей.

Нет жестких правил, которые вы должны соблюдать, чтобы быть правильными. Вы должны смотреть на свои потребности, свои требования и на какие у вас ограничения.

Удачи.