Приложения WCF/Client - куда бизнес-логика должна пойти?
Надлежащие Регулярные выражения не были бы в состоянии сделать это, поскольку Вы оставите область Регулярных языков для приземления в территориях Бесконтекстных языков.
, Тем не менее, пакеты "регулярного выражения", которые предлагают много языков, строго более мощны.
, Например, Lua регулярные выражения имеют" %b()" устройство распознавания, которое будет соответствовать сбалансированной круглой скобке. В Вашем случае Вы использовали бы" %b{}"
, Другой сложный инструмент, подобный sed, gema, где Вы будете соответствовать сбалансированным фигурным скобкам очень легко {#}.
Так, в зависимости от инструментов у Вас есть в Вашем распоряжении свое "регулярное выражение" (в более широком смысле), может быть в состоянии соответствовать вложенной круглой скобке.
3 ответа
Мой голос будет ясным:
- поместите как можно больше проверок целостности данных в базу данных
- поместите любые другие проверки бизнес-логики на уровень бизнес-логики на стороне сервера service
- помещает на клиентский уровень только простые проверки, такие как «требуется поле» и т. д., оптимально автоматически определяемые из модели базы данных или вашей бизнес-модели
Почему база данных?
SQL в любой форме или форме имеет некоторые очень простые и очень мощные возможности проверки - убедитесь, что материал уникален, убедитесь, что реляционная целостность между таблицами задана и так далее - ИСПОЛЬЗУЙТЕ ЭТО ! Если вы выполняете эти проверки в базе данных, то независимо от того, как ваш пользователь в конечном итоге подключается к вашим данным (ужасный сценарий: менеджеры могут напрямую подключаться к вашим таблицам с помощью Excel для выполнения некоторой работы с бизнес-аналитикой ...), эти проверки будут проводиться и будут выполняться. Обеспечение целостности данных - высшее требование в любой системе.
Почему бизнес-логика на сервере?
По той же причине, которую упоминали другие ответчики: централизация. Вы не хотите, чтобы бизнес-логика и ваши чеки находились только в клиенте. Что, если какой-то другой отдел в вашей компании или сторонний внешний консультант внезапно начнет использовать ваш сервис, но все проверки и бизнес-проверки не на месте, поскольку они не знают о них? Не очень хорошо ......
Логика в клиенте
Да, конечно - вы также хотите поставить несколько простых проверок в клиент, особенно если это веб-приложение. Такие вещи, как «это поле является обязательным» или «максимальная длина этого поля» и т. Д., Должны быть реализованы как можно раньше. Идеально, это будет автоматически получено клиентами из уровня базы данных / сервиса. Серверные элементы управления ASP.NET имеют проверку клиента, которая может быть включена автоматически, Silverlight RIA Services может снимать ограничения данных в вашей внутренней модели данных и передавать их на клиентский уровень.
Я думаю, что "правильный" зависит от архитектуры вашего приложения. Несомненно, разделение проблем имеет ценность. Похоже, ваш босс считает, что текущая модель заключается в использовании сервера в качестве уровня доступа к данным, который сопоставляет базу данных с бизнес-объектами, и что бизнес-логика должна быть реализована на клиенте.
Вы все еще можете разделить проблемы, будет ли бизнес-логика реализована на клиенте или сервере. Важно не то, где вы выполняете обработку, а то, насколько четко вы спроектировали интерфейсы между уровнями приложения.
Возможно, будет полезно узнать больше о клиенте. Вы имеете дело с браузером / клиентом Javascript? Если так, то я d поддерживать как можно больше обработки на сервере и отправлять данные клиенту более или менее в той форме, в которой вы хотите, чтобы они отображались.
Если это клиент C #, тогда у вас будет гораздо больше возможностей для работы с этой стороны. Вероятно, вы могли бы воссоздать ответы службы WCF в тех же классах бизнес-объектов, которые вы использовали на стороне сервера, и получить ту же мощность, что и на сервере. (Просто поделитесь классами бизнес-объектов между двумя решениями.)
Для этого нет жесткого правила, но в этом случае я бы сказал, что ваш босс ошибается больше, чем вы :) У всех будет немного другое мнение по этому поводу, и может может быть ряд причин, по которым ваша бизнес-логика размещается в местах, отличных от бизнес-уровня, но редко есть причина для размещения ее в клиентском приложении - вы можете возразить, что, когда она находится в клиентском приложении, это пользовательский интерфейс или правило представления, а не бизнес-правило.
Если веб-сервисы будут использоваться несколькими приложениями, то, насколько это возможно, вам нужна бизнес-логика на стороне веб-сервиса. На самом деле у меня был бы очень тонкий слой веб-сервисов, все, что он делает, это принимает вызов, а затем передает выполнение на фактический бизнес-уровень. Я бы также сделал сопоставление между данными базы данных и объектами бизнес-данных на уровне базы данных, а не на бизнес-уровне.