Строительство объекта на клиентском или бизнес уровне?

Question

Из множества начальных наборов .NET я заметил, что создание бизнес-объектов часто выполняется на уровне клиента. Затем бизнес-объект передается на бизнес-уровень для манипулирования, сериализации в базу данных и т. Д. Не следует ли этот код абстрагировать от бизнес-уровня, чтобы клиенту нужно было только передать необходимые данные? Есть ли какое-то преимущество в наличии бизнес-уровня с абстракциями CRUD, которые принимают только объекты в качестве аргументов?

Answer 1

Я согласен с вами, что взаимодействие с бизнес-уровнем должно быть максимально простым, со сложными типами и другой сложностью скрытыми , или в чем смысл. В точке, где ваши пользовательский интерфейс и бизнес-объекты подключены, сложность должна быть как можно ближе к 0.

Я могу представить себе сценарии, где построение относительно сложных типов в этой точке было бы законным. Чем меньше сайт, тем больше вероятность, что <3 уровня могут быть лучше, чем строгие 3 уровня. Таким образом, чтобы быть непредвзятыми в отношении стартовых наборов, которые вы видите: возможно, охват настолько мал, что строгое разделение интересов будет чрезмерным, и их подход вполне может подойти для ситуации. Или то, что они делают, настолько <em>сложное , что это лучший способ справиться с этим. Чем сложнее соединение или интеграция, или если есть модель подключаемого модуля или что-то еще, то на первый взгляд может показаться слишком сложный тип, который обеспечивает согласованный гибкий интерфейс. Иногда небольшая сложность в одном месте спасает вас от множества других. Но чаще всего это не так. Я думаю, что то, что вы видите как плохое, действительно , , плохой .

1. Многие Microsoft Quick-Start Демонстрации а шаблоны действительно плохие архитектура . Модель веб-форм само по себе не поддается разделение интересов. Вот увидишь много официальных примеров, которые код спагетти кошмары. Бизнес, БД и пользовательский интерфейс жить вместе - это ужасная гармония.
2. Если вы говорите о третьей стороне SDK: многие из них требуют сложных типы, передаваемые бизнес-объектам потому что они были портированы из C ++ но никогда не пересматривался объектно-ориентированный. Пару раз мне приходилось делать безумных типов , чтобы перейти к некоторым программным объектам обработки изображений, где по логике нужны только два простых параметра-значения.

Answer 2

Обычно я выполняю этот тип работы в Сервисе или на уровне доступа к данным. То есть для меньшего проекта мой уровень доступа к данным возвращает мои доменные объекты. Для более крупных проектов я бы использовал сервисный уровень для обработки сложных объектов и вызова бизнес-логики.