Пользовательский интерфейс, уровень бизнес-логики, уровень данных и где размещать веб-сервисы

Question

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

Какой дизайн будет более правильным

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

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

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

Answer 1

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

Answer 2

Я бы сказал, третий. Я склонен думать о веб-сервисах как о другом уровне представления.

Подумайте об этом так: у вас есть веб-интерфейс, который вызывает код вашего бизнес-уровня для таких вещей, как создание нового пользователя (User.Add), поиск всех продуктов, соответствующих данному описанию (Products.FindByDescription) и т. Д. .

Теперь вы можете повторно использовать этот же код бизнес-уровня для создания набора общедоступных веб-сервисов, которыми могут воспользоваться третьи стороны. Может существовать метод, который добавляет пользователя - который вызывает ваш внутренний метод User.Add (), другой - для поиска товаров и т. Д.

Получается параллельный набор презентаций / интерфейсов с одними и теми же базовыми данными и бизнес-логикой.

За кулисами (полностью за пределами веб-служб или уровней пользовательского интерфейса) бизнес-уровень вызывает уровень доступа к данным, который заботится о физических запросах к базе данных. Если бы вам пришлось перейти на другую СУБД, в идеале вы (в теории) должны быть в состоянии перестроить слой данных для новой базы данных, и все должно работать просто.

Ваш бизнес-уровень содержит правила, например, имя пользователя должно быть длиной от 4 до 15 символов; пользователи могут только искать и загружать продукты, которые находятся в магазине, к которому у них есть доступ; и т.д.

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

Answer 3

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

Answer 4

С точки зрения того, является ли дизайн «правильным» или нет, на самом деле невозможно дать 100% ответ на правильность дизайна без полного контекста. Какие требования (функциональные и нефункциональные)? Какие цели дизайна вы хотите достичь? Насколько важна каждая цель?

Единственная цель, о которой упоминается в вашем вопросе, заключается в том, что вы хотите повторно использовать бизнес-логику в другом приложении. Когда я хочу использовать бизнес-логику приложения стандартным образом, я выбираю веб-сервисы. Поэтому, основываясь исключительно на одном вашем требовании, я бы сказал, что вариант 1 (UI-> Веб-сервис-> Бизнес-уровень-> Уровень данных) является хорошим выбором.

Answer 5

Из вашего описания вы не указали причину, по которой вам понадобится использовать слой веб-службы. Предполагая, что ваша база данных доступна вашей системе пользовательского интерфейса, то есть в той же сети, что и брандмауэр, базовый уровень бизнес-объектов, который будет использоваться кодом пользовательского интерфейса вашего веб-сайта (я полагаю, на стороне сервера), отвечает вашим требованиям.

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

Answer 6

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

Answer 7

Выезд: http://www.icemanind.com/layergen.aspx

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

Если у вас нет причин использовать веб-сервис, я бы не стал.