Бизнес-логика не на уровне представления

Question

В приложении RIA вы должны поместить как можно больше бизнес-логики вне слоев RIA (flash / silverlight и т. Д.). В чем причина этого? Любая логика, которая входит в уровень представления, получает преимущество от более быстрого выполнения ...

Это потому, что технологии RIA, скорее всего, потребуется подтяжка лица в будущем, и вам придется переписать всю бизнес-логику?

Answer 1

Я не уверен, что согласен с вашей предпосылкой, что вы "должны" использовать бизнес-логику вне клиента. Вы должны переместить бизнес-логику за пределы уровня пользовательского интерфейса, но обычно до того, как вы подключитесь к внутреннему веб-сервису, осталось еще несколько клиентских слоев. Например, типичное приложение Silverlight основано на модели MVVM, которая предписывает View, в котором нет бизнес-логики, ViewModel, который имеет довольно хороший кусок проверки и бизнес-логики, и модель, в которой есть все остальное. И все это на стороне клиента.

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

Другими словами, в идеале, ваша бизнес-логика и проверки должны выполняться как на клиенте, так и на сервере: на клиенте, потому что вам нужна оперативность, и на сервере, потому что вам нужна безопасность. Вопрос в том, как это получить, и нет идеальных ответов.

Одним из подходов, обычно используемых в приложениях Silverlight (я менее знаком с Flash), является использование служб WCF RIA, которые позволяют создавать проверки в одном месте, которые выполняются как на клиенте, так и на сервере. Даже если вы не используете платформу WCF RIA Services, вы все равно можете получить почти тот же эффект, связавшись с исходным кодом ваших классов проверки / бизнес-логики как на клиенте, так и на веб-сервисе - это больше работы, но все же, вероятно, меньше работы, чем написание ваших проверок дважды и их синхронизация вручную.

Answer 2

Business Logic - это комплексная задача.

Будут ли ваши пользователи вводить даты?Если это так, интерфейс должен знать, что это даты, чтобы дать им возможность выбора и предотвратить недопустимые записи.Может быть, даже ограничить записи в диапазоне.Это бизнес логика.Как вы можете сохранить его и по-прежнему иметь значимый интерфейс?

Будут ли пользователи въезжать в любой штат США или провинцию?Если это так, должен быть заполнен раскрывающийся список, а это означает, что пользовательский интерфейс «знает» о внешних ключах.

Будут ли поля, которые пользователь может видеть, но не изменять?Почему или почему нет?Это бизнес логика.Будут ли ограничения на то, что определенные пользователи могут делать на определенных условиях?Это бизнес-логика.

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

Но, в конце концов, вопрос не в том, как не допустить BL в пользовательский интерфейс, вы не можете этого сделать, вопрос в том, какие виды BL будут в пользовательском интерфейсе.Это сводится к типам, диапазонам значений, разрешенным операциям и т. Д.

Таким образом, либо пользовательский интерфейс получает всю эту информацию с более низкого уровня, либо часть ее воспроизводится на уровне пользовательского интерфейса.

Answer 3

Итак, одна из причин - ремонтопригодность. Если клиент уже распространен повсеместно, вам не нужно переустанавливать или перезагружать его при изменении простого бизнес-правила. Просто разверните изменения в серверной части, и все готово.

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

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

Как сказал @Ken Smith, вам непременно следует избегать бизнес-логики на уровне вашего пользовательского интерфейса. Это для тестируемости, ремонтопригодности, проектируемости и т. Д. Но это не означает, что все идет к концу, особенно в приложении RIA со значительными правилами пользовательского интерфейса. В приложении MVVM (Silverlight) или приложении Presentation Model (Flex) пользователь помещает UH BEHAVIOR в слой ViewModel или PresentationModel. Затем вы помещаете любой уровень бизнес-логики в вашу модель. Эта бизнес-логика может быть просто проверкой. Это может быть больше. Это зависит от вашей архитектуры.