Возможно ли, чтобы бизнес-логика не ползла в точку зрения?

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

В большинстве случаев возникают такие проблемы, как «Если пользователь выбрал опцию x, то приложение должно разрешить ему предоставлять информацию для y, если нет, то он /она должен предоставить информацию z». Или выполните некоторую операцию AJAX, которая должна применить некоторые изменения к модели, но НЕ выполнять их до тех пор, пока пользователь явно не запросит это. Это некоторые из самых простых проблем, с которыми я столкнулся, и я не могу понять, как можно избежать сложной логики в представлении.

Большинство прочитанных мной книг, описывающих MVC, обычно демонстрируют некоторые очень тривиальные примеры, такие как операции CRUD, которые просто обновляют данные на сервере и отображают их, но CRUD не подходит для большинства богатых приложений.

Можно ли получить представление без бизнес-логики?

31 голос | спросил vdaras 20 Maypm14 2014, 15:04:36

7 ответов


21
  

Можно ли получить представление без бизнес-логики?

Я нахожу это обманчиво трудным вопросом для ответа. (Мыслящий вопрос!)

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

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

Но, как и все, есть компромиссы. Лучшее концептуальное местоположение не может быть лучшим местом по другим причинам. Возможно, на вашем веб-сервере слишком много нагрузки, поэтому вы добавляете javascript на свои веб-страницы, чтобы ловить легкие ошибки ввода до того, как они попали на ваш сервер; теперь у вас есть какая-то бизнес-логика.

Само представление не имеет ценности без бизнес-логики. И чтобы быть эффективным в использовании и отображении, неявно или явно, представление будет иметь некоторые знания о бизнес-процессах, происходящих за ним. Мы можем ограничить этот объем знаний, и мы можем оцеплять его части, но практические соображения часто вынуждают нас «разорвать» разделение проблем.

ответил JvR 20 Maypm14 2014, 16:23:54
8

Я обычно делаю это: если пользователь выбрал опцию x, то вызов вызывает

controller->OptionXChanged()

Затем контроллер включит y в представлении:

view->SetEnableInfoY(True) // suppose False=SetDisable

Представление уведомляет диспетчера о том, что происходит, не решая ничего.

ответил Fil 20 Maypm14 2014, 15:19:19
4

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

С точки зрения «Вид» он предоставляет только систему InfoY или InfoZ. Просто потому, что ваша реализация пользовательского интерфейса выполняет некоторые динамические обновления, основанные на выборе оператора (то есть, с помощью функции InfoY или InfoZ), не делает функциональную бизнес-логику. Это действительно логика реализации. Вы вполне могли бы просто дать оператору выбор для ввода InfoY или InfoZ без всякой возможности. В этом контексте вы бы все еще считали его бизнес-логикой? Если нет, то то же самое применимо для динамического включения /отключения информационных полей.

То же самое касается примера фиксации. Это две отдельные операции, которые система требует правильной работы. Ваш вид должен быть способен инициировать правильные действия для выполнения желаемых функций. Знает ли вам, как использовать вашу систему, означает, что бизнес-логика протекает? Я могу видеть, как кто-то может сказать «да», но если вы так верите, то реальность такова, что отделять бизнес-логику от чего-либо нет. Вы должны знать, что система делает /работает, чтобы достичь чего-либо значимого. В противном случае было бы просто создать единый общий View и Controller, который будет работать со всеми возможными MVC-приложениями. То, что мы знаем, невозможно.

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

ответил Dunk 20 Maypm14 2014, 20:24:43
1

Я работаю так (Struts2 + Hibernate):

Мои действия Struts отвечают только за информацию о шоу в веб-браузере. Не думайте.

Пользователь -> Действие -> Сервис -> Репозиторий -> Доступ к данным

Или:

Я хочу видеть -> Как видеть -> Что делать -> Как получить -> Где получить

Итак, в первом слое (вид) у меня есть что-то вроде:

public String execute ()   {
    try {
        CourseService cs = new CourseService();
        Course course = cs.getCourse(idCourse);
    } catch (NotFoundException e) {
        setMessageText("Course not found.");
    } catch (Exception e) {

    }
    return "ok";
}

Как вы видите, мой «взгляд» не думает. Он запрашивает услугу (для управления курсами) определенного курса. Эта услуга может многое сделать, например, отчеты, серасы и т. Д. Результаты всегда представляют собой список или определенный объект (например, пример). Услуги - это настоящая машина, применяются правила и доступ к репозиторию (для управления данными).

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

Служба знает, что делать, но не знает, как это показать. Представление знает, как показать, но не знает, что делать. То же самое с Service /Repository: служба отправляет и запрашивает данные, но не знает, где находятся данные и как их принимать. Репозиторий «подготавливает» необработанные данные для создания объектов, чтобы служба могла работать.

Но репозиторий ничего не знает о базе данных. Тип базы данных (MySQL, PostgreSQL, ...) относится к DAO.

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

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

Бизнес-логика - это Сервис. Но как взаимодействовать с этим является просмотр. Какую кнопку теперь показывать? Может ли пользователь увидеть эту ссылку? Подумайте, что ваша система - это консольная программа: вы должны отрицать, что неправильный пользователь выбирает #> myprogram -CourseService -option=getCourse -idCourse=234 или останавливает его, чтобы нажать клавиши, чтобы написать это команда?

Говоря в веб-системах (Struts + JavaEE) У меня есть отдельный пакет контроллера GUI. В действии Action я даю зарегистрированный пользователь, и класс дает мне кнопки (или любой элемент интерфейса, который я хочу).

                <div id="userDetailSubBox">
                    <c:forEach var="actionButton" items="${actionButtons}" varStatus="id">
                        ${actionButton.buttonCode}
                    </c:forEach>
                </div>

И

private List<ActionButton> actionButtons;

Не забудьте сохранить это из служб. Это ПРОСМОТРЕТЬ. Храните его в действиях Struts. Любые взаимодействия с интерфейсом должны быть полностью отделены от реального бизнес-кода, поэтому, если вы портируете свою систему, вам будет легко сократить то, что вам больше не понадобится.

ответил Magno C 20 Maypm14 2014, 22:28:00
1
  

В большинстве случаев возникают такие проблемы, как «Если пользователь выбрал опцию x, то приложение должно разрешить ему предоставлять информацию для y, если нет, то он /она должен предоставить информацию z"

Это логика для модели, а не вид. Это может быть «модель представления», созданная специально для поддержки пользовательского интерфейса, но она по-прежнему является модельной логикой. Контрольная последовательность:

  • Контроллер прикрепляет обработчик для событий просмотра
  • View прикрепляет обработчик для событий модели.
  • Пользователь выбирает параметр X.
  • Представление вызывает событие «Выбранный вариант X»
  • Контроллер принимает событие и вызывает model.selectOptionX ()
  • Модель вызывает событие «Изменено состояние модели»
  • Представление получает событие с измененной моделью и обновляет представление в соответствии с новым состоянием: inputY.enable(model.yAllowed()); inputZ.enable(model.zAllowed());

UI View Controller Model |.checkbox X checked.> | | | | | .. X selected ...>| | | | |-----> set X ------->| | | | | | |< .............state changed ............| | | | | | |-------------- Get state --------------->| | | | | | |<----------- new state ------------------| | <-- UI updates ------| Это классический шаблон MVC. Можно полностью протестировать логику модели отдельно от пользовательского интерфейса. Контроллер и вид очень тонкие и легко проверяются.

=== В ответ на Dunk ===

Модель в шаблоне MVI UI (обычно) не модель бизнес-объекта. Это всего лишь модель для состояния пользовательского интерфейса. В настольном приложении он может содержать ссылки на несколько бизнес-моделей. В приложении Web 2.0 это класс Javascript, который содержит состояние пользовательского интерфейса и передает через AJAX сервер. Очень важно иметь возможность записывать единовременные тесты модели состояния пользовательского интерфейса, так как именно там обнаруживается большинство ошибок пользовательского интерфейса. Вид и контроллер должны быть очень тонкими разъемами.

ответил kevin cline 20 Maypm14 2014, 22:45:39
0

Бизнес-логика больше похожа на If X then return InfoType.Y, тогда пользовательский интерфейс будет отображать поля на основе результата, возвращаемого доменом.

// Controller method pseudocode
option changed routine

    get selected option

    get required info type from domain routine based on selected option

    display fields based on required info type

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

ответил Yorro 20 Maypm14 2014, 15:24:27
0
  

Если пользователь выбрал опцию x, приложение должно включить его   для предоставления информации для y, если нет, то он /она должен предоставить информацию z ".

Существуют входы, которые имеют условно установленные значения. В большинстве сред GUI существует много вариантов того, как обрабатывать входные данные, особенно время. Выбранный параметр (в этом случае x) должен быть обработан, поэтому отправьте его на контроллер. Отправьте его, когда пользователи покидают поле ввода. Подождите, пока они не нажмут на другой объект или не ударят. Не имеет значения для бизнес-логики. Так или иначе, контроллер будет принимать решение и должен сказать мнение, «y требуется».

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

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

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

ответил JeffO 21 Maypm14 2014, 16:43:40

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132