Как вы разрабатываете свое приложение для разных уровней презентации?

Question

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

Допустим, у вас есть экран редактирования учетной записи пользователя. Вот типичный фрагмент кода, который пишут разработчики: Открытый класс Handler расширяет StupidFrameworkBaseHandler {

// This is analogous to Struts Action
// Handlers are invoked by your controller.
    public void execute() {
        // get form elements
        }
    }
    }

Чтобы представить концепцию форм-бинов, был объявлен абстрактный метод getFormBean (), расширяющий класс StupidFrameworkBaseHandler. Этот метод будет вызываться классом BaseHandler. Итак, на данный момент код выглядит так:

public class Handler extends ExtendedStupidFrameworkBaseHandler {

public void execute() {
UserEditFormBean bean = (UserEditFormBean) baseBean;
// business layer classes.
}

public BaseBean getFormBean() {
// get HTTP Request parameters and build an object.
UserEditFormBean bean = new UserEditFormBean();
bean.setUser(httpRequest.getParam("whatever"));
// other setters...
}
return bean;
}

В более ранних приложениях, которые разрабатывались с использованием этой инфраструктуры, кодеры все кодировали в Handler - получение соединения БД, бизнес-логики и т. Д. Чтобы изменить это понятие бизнеса и уровня DAO, было введено в моем текущем приложении.

Итак, окончательный код выглядит примерно так:

    public class Handler extends ExtendedStupidFrameworkBaseHandler {

    public void execute() {
        UserEditFormBean bean = (UserEditFormBean) baseBean;
        UserBO busObj = new UserBO();
        busObj.validateUserDetailsAndSave(bean); // I know this sucks..
    }

    public BaseBean getFormBean() {
        // grab user input from form and return a form bean instance.
    }

}

И бизнес-уровень выглядит так:

   public UserBO extends BaseBO {

    public void validateUserDetailsAndSave(UserEditFormBean bean) {
    UserDAO dao = factory.getDao("user");
    // call getters on bean, do some validations, throw business exceptions.
    User objUser = new User();
    object.setUserName(bean.getUserName());
    // few more setters here on User -> that is the model.
    dao.update(objUser);
    }

    }

Я считаю этот общий дизайн УЖАСНЫМ по многим причинам:

1. UserBO - это класс, который не имеет состояния. Это просто набор методов с процессуальный код.
2. Если вы называете их слоями, тогда каждый слой не должен зависеть от другой: UserBo всегда будет ожидать один тип FormBean для каждого метод и если бы я игнорировал HTML и повторно использовать тот же класс BO из автономное Java-приложение, я бы никогда не сможет без создания FormBeans как params.
3. Код выглядит ужасно и unmaintaineable.

Итак, мой вопрос здесь будет:

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

Answer 1

Я бы посоветовал вам взглянуть на Spring Framework . Он имеет концепцию контейнера IoC (инверсия управления) и в значительной степени опирается на шаблон внедрения зависимостей. Последний шаблон чрезвычайно полезен для разделения ваших объектов, что является основной вещью, которую вы должны гарантировать при структурировании уровней приложения. Ваши слои должны быть полностью независимыми. Так, например, ваш бизнес-уровень НИКОГДА не должен ссылаться на вещи из вашего уровня презентации. Чтобы убедиться, что вы можете указать, например, следующую ситуацию, когда у вас есть один и тот же бизнес-уровень для уровня веб-презентации, а также для отдельного клиентского приложения (уровень презентации). Если это возможно, то вы на правильном пути.

Чтобы отделить ваши слои, вы всегда должны определять четкие «контракты» через соответствующие интерфейсы. Так, например, у вас должен быть класс бизнес-уровня (или службы) MyService.java и соответствующий IMyService.java (или MyServiceImpl.java и MyService.java, как вам удобнее), где IService.java - это интерфейс, определяющий методы, которые раскрывается фактической реализацией класса MyService, который в основном содержит вашу бизнес-логику. И поэтому ваш уровень представления будет просто использовать интерфейс для подключения к вашему бизнес-уровню. И вот тут Spring вступает в игру с внедрением зависимости. На вашем уровне представления у вас будет:

...
public void someMethod(..){
  IService service = new MyService();
  service.doSomething(...);
  ..
}

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

Надеюсь, это дало вам приблизительное представление о том, как это должно быть сделано.

Answer 2

Вы правы в том, что вы должны разделить свой бизнес и уровень представления.

Я бы поддержал рекомендацию Spring Framework, однако, учитывая, что вы работаете с веб-приложениями, я думаю, что вам будет особенно интересен Spring Web MVC , поскольку он предоставляет все функции, которые вам нужны.