Приложения WCF / Client - куда должна идти бизнес-логика?

Question

Мы создаем веб-сервис WCF с использованием WSSF. Идея состоит в том, что он предоставит нашу основную базу данных через сервис и позволит нам создавать различные приложения и веб-сайты поверх сервиса. Сейчас я создаю простое клиентское приложение, которое будет загружать некоторые данные из этого сервиса, манипулировать ими, а затем передавать их пользователю в виде файла CSV отчета.

Теперь вопрос в том, где должна располагаться бизнес-логика (которая манипулирует данными)? Я подумал, что я бы положил его в сервис. У меня уже есть бизнес-слой с простыми объектами, которые сопоставляют базу данных (клиент, заказ и т. Д.) Почти один к одному. Я подумал, что сделаю несколько объектов «более высокого уровня» для манипулирования данными. Например, используя клиента, заказ и другие объекты, создавая отчет и т. Д., Я подумал, что лучшим местом для этого будет бизнес-уровень для сервиса. Таким образом, мы можем при необходимости использовать эту логику для различных приложений.

К сожалению, мой босс не согласен. Он хочет «разделения интересов» и говорит, что правильное место для этой логики будет на бизнес-уровне внутри клиентского приложения, а не в сервисе. Я думаю, это может быть проще, но я хотел бы использовать мою мощную объектную модель внутри бизнес-уровня сервиса для написания этого кода. Объекты, предоставляемые сервисом, не являются «реальными» объектами и на самом деле представляют собой просто легкие структуры данных без возможности полной объектной модели, которая существует внутри бизнес-уровня сервиса.

Что вы, ребята, думаете?

Answer 1

Мой голос будет понятен:

• поместил столько же проверок целостности данных в базу данных
• помещает любые другие проверки бизнес-логики в слой бизнес-логики на стороне сервера службы
• помещает только простые проверки, такие как «обязательное поле» и т. Д., На уровень клиента, оптимально автоматически определяемый из модели базы данных или вашей бизнес-модели.

Почему база данных?
SQL в любой форме или форме имеет некоторые базовые и очень мощные возможности проверки - убедитесь, что материал уникален, убедитесь, что целостность отношений между таблицами задана и т. Д. - ИСПОЛЬЗУЙТЕ ЭТО ! Если вы выполните эти проверки в базе данных, то независимо от того, каким образом ваш пользователь в конечном итоге подключится к вашим данным (ужасный сценарий: менеджеры смогут напрямую подключаться к вашим таблицам с помощью Excel для выполнения какой-либо работы Business Intelligence ......), эти проверки будут на месте и будут применяться. Обеспечение целостности данных является обязательным требованием в любой системе.

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

Логика в клиенте
Да, конечно - вы также хотите поставить несколько простых проверок в клиенте, особенно если это веб-приложение. Такие вещи, как «это поле обязательно для заполнения» или «максимальная длина этого поля» и т. Д., Должны применяться как можно раньше. В идеале это будет автоматически выбираться клиентами из уровня базы данных / сервиса. Серверные элементы управления ASP.NET имеют клиентскую проверку, которая может быть автоматически включена. Службы RIA Silverlight могут подобрать ограничения данных в вашей внутренней модели данных и перенести их на уровень клиента.

Answer 2

Нет жестких и быстрых правил для этого, но в этом случае я бы сказал, что ваш начальник более неправ, чем вы :) У каждого будет несколько иное мнение по этому поводу, и может быть ряд причин, по которым ваш бизнес-логика размещается не в бизнес-уровне, а в других местах, но редко есть причина для ее размещения в клиентском приложении - можно утверждать, что когда она находится в клиентском приложении, то это скорее пользовательский интерфейс или правило представления, чем бизнес-правило .

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

Answer 3

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

У вас все еще может быть разделение интересов, реализована ли бизнес-логика на клиенте или на сервере. Это не то, где вы выполняете обработку, а то, насколько четко вы спроектировали интерфейсы между уровнями приложения.

Это может помочь узнать больше о клиенте. Вы имеете дело с браузером / клиентом Javascript? Если это так, то я бы сохранял как можно больше обработки на сервере и отправлял данные клиенту более или менее в той форме, в которой вы хотите, чтобы они отображались.

Если это клиент C #, тогда у вас гораздо больше возможностей для работы с этой целью. Вероятно, вы могли бы преобразовать ответы службы WCF в те же классы бизнес-объектов, которые вы использовали на стороне сервера, и получить те же возможности, что и на сервере. (Просто разделите классы бизнес-объектов между двумя решениями.)