Пользовательский интерфейс, уровень бизнес-логики, уровень данных и где размещать веб-сервисы
Мы разрабатываем веб-приложение. Мы хотим, возможно, повторно использовать работу, которую мы делаем здесь, для другого приложения, которое будет использовать ту же базу данных, и использовать те же бизнес-правила для чтения и записи в эту базу данных.
Какой дизайн будет более правильным
Пользовательский интерфейс вызывает веб-сервисы, которые будут использовать бизнес-объекты, содержащие бизнес-логику, которые будут взаимодействовать со слоем доступа к данным.
Пусть пользовательский интерфейс использует бизнес-объекты, содержащие бизнес-логику, которая будет вызывать веб-службы, которые затем будут взаимодействовать со слоем доступа к данным.
Иметь пользовательские бизнес-объекты пользовательского интерфейса, содержащие бизнес-логику, которая будет взаимодействовать со слоем доступа к данным.
7 ответов
Не смешивайте логический дизайн с физическим дизайном. Логический дизайн работает над слоями, а физический дизайн - ярусами. Веб-сервис не является слоем. Это просто уровень. В логическом проектировании существует стандартный подход: уровень пользовательского интерфейса-> уровень BL -> DAL. В физическом проектировании все уровни могут находиться в одном клиентском приложении, соединяющем локальную базу данных, или могут быть распределены по удаленным уровням. Но для распределенных приложений обычно добавляется еще один уровень: прикладной уровень, который скрывается от связи уровня BL по проводам.
Я бы сказал, третий. Я склонен думать о веб-сервисах как о другом уровне представления.
Подумайте об этом так: у вас есть веб-интерфейс, который вызывает код вашего бизнес-уровня для таких вещей, как создание нового пользователя (User.Add), поиск всех продуктов, соответствующих данному описанию (Products.FindByDescription) и т. Д.
Теперь вы можете повторно использовать этот же код бизнес-уровня для создания набора общедоступных веб-служб, которыми могут воспользоваться третьи стороны. Может быть метод, который добавляет пользователя - который вызывает ваш внутренний метод User.Add(), другой для поиска товаров и т. Д.
Получается параллельный набор презентаций / интерфейсов с одними и теми же базовыми данными и бизнес-логикой.
За кулисами (полностью за пределами веб-служб или уровней пользовательского интерфейса) бизнес-уровень вызывает уровень доступа к данным, который заботится о физических запросах к базе данных. Если бы вам пришлось перейти на другую СУБД, в идеале вы должны (и теоретически) иметь возможность перестроить слой данных для новой базы данных, и все должно работать просто.
Ваш бизнес-уровень содержит правила, например, имя пользователя должно быть длиной от 4 до 15 символов; пользователи могут только искать и загружать товары, которые находятся в магазине, к которому у них есть доступ; и т.п.
Если вы решите изменить бизнес-правило (например, пользователю разрешено искать товары в любом магазине в их состоянии), то вы меняете его сразу, и вам не нужно прикасаться к веб-службе или пользовательскому интерфейсу, чтобы заставить его работать.
С точки зрения того, является ли дизайн "правильным" или нет, на самом деле невозможно дать 100% ответ на правильность дизайна без полного контекста. Какие требования (функциональные и нефункциональные)? Какие цели дизайна вы хотите достичь? Насколько важна каждая цель?
Единственная цель, о которой упоминается в вашем вопросе, заключается в том, что вы хотите повторно использовать бизнес-логику в другом приложении. Когда я хочу использовать бизнес-логику приложения стандартным образом, я выбираю веб-сервисы. Поэтому, основываясь исключительно на одном вашем требовании, я бы сказал, что вариант 1 ( UI-> Веб-сервис-> Бизнес-уровень-> Уровень данных) является хорошим выбором.
Из вашего описания вы не указали причину, по которой вам понадобится использовать слой веб-службы. Предполагая, что ваша база данных доступна вашей системе пользовательского интерфейса, то есть в той же сети, что и брандмауэр, базовый уровень бизнес-объектов, который будет использовать код пользовательского интерфейса вашего веб-сайта (я полагаю, на стороне сервера), отвечает вашим требованиям.
Включите уровень веб-службы, когда расстояние между вашей системой пользовательского интерфейса и вашим уровнем данных начнет пересекать границы, в которых уровень доступа к данным или уровень бизнес-логики начнут сталкиваться с трудностями.
По логике вещей, веб-сервисы принадлежат уровню UI. Представьте, что "Пользователь" - это не только человек, но и другая система, и это становится понятным. Поддержание строгого разделения интересов между этими логическими уровнями позволит вам легко внедрить и поддерживать ваше приложение.
Проверить: http://www.icemanind.com/layergen.aspx
То, как это должно происходить, это то, что у вас есть уровень пользовательского интерфейса вверху, уровень данных внизу и бизнес-уровень между ними. Каждый уровень может общаться только со слоем под ним. Таким образом, пользовательский интерфейс взаимодействует только с бизнес-уровнем... бизнес-уровень взаимодействует только с уровнем данных. Ваш пользовательский интерфейс никогда не должен взаимодействовать с уровнем данных, а уровень данных никогда не должен взаимодействовать с вашим интерфейсом.
Если у вас нет причин использовать веб-сервис, я бы не стал.
Вы слышали что-нибудь о слое Service? Я думаю, что вы можете использовать сервисный уровень для своих транзакций и операций, а использование фасадного уровня помогает вам изолировать и управлять доступом из пользовательского интерфейса к уровню доступа к данным прямо или косвенно после посещения бизнес-уровня. это зависит от ваших требований.