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

Question

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

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

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

Что вы, ребята, думаете? Большое спасибо за помощь.

Приветствия Марк

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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