Я разрабатываю приложение ASP.net, которое использует веб-службы. От моего приложения нет соединений с базой данных - все действия обрабатываются с помощью веб-служб.
В слое пользовательского интерфейса я могу выполнить настройки и проверки данных с помощью нескольких строк кода Linq. Каковы недостатки, если у меня нет бизнес-уровня для моего приложения?
Включение всей вашей проверки и бизнес-логики в собственный уровень хорош по многим причинам.
Он сохраняет локализацию всей вашей бизнес-логики и в одном месте. Будущие изменения будут намного проще в результате.
Это позволяет вам легче unit test вашу бизнес-логику. Это большой. Очень сложно писать автоматические модульные тесты против вашей бизнес-логики, если этот код тесно связан с вашей веб-страницей или формой окна.
Он значительно упрощает ваш интерфейс.
См. также: принцип единой ответственности (вкратце, ваши классы пользовательского интерфейса должны делать пользовательские интерфейсы, а не бизнес-логику).
Если ваш код пользовательского интерфейса обрабатывает не связанные с UI вещи, такие как бизнес-логика, тогда в коде отсутствует разделение проблем. Предположим, вы хотите использовать совершенно другой интерфейс - например, вы хотите переключиться с веб-службы на создание фактического веб-сайта/приложения. Вы должны полностью воспроизвести всю свою бизнес-логику на новом уровне пользовательского интерфейса, потому что бизнес-логика привязана к текущему пользовательскому интерфейсу.
Разделение проблем (SoC) - это процесс разделения компьютерной программы на отдельные функции, которые как можно меньше перекрывают функциональность. Вызывает озабоченность любой интерес или фокус в программе. Как правило, проблемы являются синонимом функций или поведения. Прогресс в направлении SoC традиционно достигается за счет модульности программирования и инкапсуляции (или "прозрачности" работы) с помощью скрытия информации. Многоуровневые конструкции в информационных системах также часто основаны на разделении проблем (например, уровень представления, уровень бизнес-логики, уровень доступа к данным, уровень базы данных).
SoC и SRP упрощают и упрощают:
Здесь аналогия (да, она упрощена): автомобиль частично управляется рулевым колесом и педалью газа. Рулевое колесо управляет направлением автомобиля, а педаль газа управляет скоростью автомобиля.
Водителю будет труднее управлять автомобилем безопасно и точно, если одно устройство контролирует направление и скорость автомобиля. Например, если водитель должен был нажать рулевое колесо или вытащить его, чтобы автомобиль двигался быстрее или медленнее, они могут одновременно изменить направление движения автомобиля. Аналогичным образом, водитель может случайно изменить скорость автомобиля при попытке поворота.
Сохранение разницы между двумя аспектами (скорость и направление) облегчает и безопаснее управлять.
Кроме того, в качестве принципа SOLID SRP состояния - класс должен меняться только по одной причине. Если вы не разделяете свою бизнес-логику, вы нарушаете этот принцип.
Задайте себе вопрос: есть ли в этом приложении бизнес-логика?
Вернее: Вы
В первом случае я бы сказал, что бизнес-уровень может фактически добавить ненужную сложность в простое приложение.
Во втором случае вы обязательно должны создать некоторые бизнес-объекты и попытаться отделить их от базы данных и вашего пользовательского интерфейса (высокая степень сцепления, низкая связь, инкапсуляция с скрытием информации). Сделайте свою бизнес-логику доступной для независимого модульного тестирования и спросите себя, можно ли быстро ее перенести из базы данных Oracle в SQL Server или от того, что пользовательский интерфейс winforms является приложением Silverlight с использованием той же бизнес-логики.
Что произойдет, если в будущем вы захотите использовать ту же проверку/бизнес-логику вне этого конкретного пользовательского интерфейса? возможно, это приложение должно было бы открыть веб-сервис, который включает в себя ту же логику? или вы можете работать над клиентским/серверным приложением, автономным приложением Windows и веб-приложением asp.net, все из которых используют одну и ту же логику бизнеса и проверки. В этом случае разделение проблем сэкономит вам много избыточного кода и множество возможностей для ошибок (тем самым уменьшая время отладки).