Presentation слой в 3-х уровневая архитектура

Question

Мой вопрос о различных способов реализации уровня представления в 3 уровня архитектуры

Когда мы говорим о веб-приложения в 3 яруса, то предполагается, что презентация слой browser- ориентированный и, следовательно, связывается с логическим уровнем через HTTP-протокол

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

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

Answer 1

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

• Файлы, обрабатывающие представление (JSP, Facelets и т. Д.).
• Файлы, управляющие взаимодействием между пользователем и представлением (Сервлеты, @Controller от Spring MVC, @ManagedBean от JSF и т. Д.).

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

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

• Классы, которые обрабатывают вид
• классов контроллеров, которые обрабатывают взаимодействие между пользователем и Посмотреть.

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

Что делать, если я хочу создать конкретное настольное приложение для связи с сервлетами?

Возможно, вы имеете в виду клиентское приложение, которое использует веб-службы. Веб-службы (потребляемые XML, JSON или обычный текст) могут быть частью уровня служб, который должен потребляться на уровне бизнес-логики или на уровне презентации приложения, в зависимости от того, что возвращает веб-служба. Тем не менее, я бы лучше использовал уровень веб-сервиса на уровне бизнес-логики и позволил слою представления справиться с его назначением: только логика представления.

Чтобы показать пример:

Presentation layer 
     | 
     | <<communicates>> 
     | 
     v 
Business logic layer 
     | 
     | <<communicates>> 
     | 
     v 
Web Service Layer 
     | 
(the cloud) <<communicates data using XML, JSON, etc...>> 
     | 
     v 
Web Server that resolves the Web Service call 
     | 
     | <<communicates>> 
     | 
     v 
WS Business logic layer 
     | 
     | <<communicates>> 
     | 
     v 
WS Data access layer 
     | 
     | <<communicates>> 
     | 
     v 
Data Sources (database, files, etc) 

---

Из комментариев:

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

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

класс сервлета (адаптировано из StackOverflow Servlet wiki) (часть презентации)

@WebServlet("/hello") 
public class AServlet extends HttpServlet { 
    @Override 
    protected void doGet(HttpServletRequest request, HttpServletResponse response) 
     throws ServletException, IOException { 
     //Displaying the view. 
     request.getRequestDispatcher("/WEB-INF/hello.jsp").forward(request, response); 
    } 

    @Override 
protected void doPost(HttpServletRequest request, HttpServletResponse response) 
    throws ServletException, IOException { 
    String name = request.getParameter("name"); 
    String age = request.getParameter("age"); 
    Person person = new Person(name, Integer.parseInt(age)); 
    PersonBL personBL = new PersonBL(); 
    personBL.savePerson(person); 
} 

PersonBL класс (часть бизнес-логики)

public class PersonBL { 
    //omitting configurations and all non-code related stuff for explanation purposes 
    @WebServiceRef(wsdlLocation="http://localhost:8080/helloservice/hello?wsdl") 
    private static PersonWebService personWS; 

    public void savePerson(Person person) { 
     //since is business logic layer, it can hold validations for the data 
     //before calling the web service 
     //for explanation purposes, no business logic will be added 
     //... 
     //here it will contain the logic to call the web service 
     PersonPort personPort = personWS.getPersonPort(); 
     personPort.savePerson(person); 
    } 
} 

Теперь, отправляя скелет веб-службы:

Класс PersonPort (разработчик веб-службы)

@WebService 
public class PersonPort { 
    @WebMethod 
    public void savePerson(Person person) { 
     PersonWSBL personWSBL = new PersonWSBL(); 
     personWSBL.savePerson(person); 
    } 
} 

PersonWSBL класс (бизнес-логика в Web Service)

public class PersonWSBL { 
    public void savePerson(Person person) { 
     //it can contain business rules to apply before executing the operation 
     //for example purposes, there won't be any rules to apply 
     //... 
     PersonDAO personDAO = new PersonDAO(); 
     personDAO.savePerson(person); 
    } 
} 

класс PersonDAO (уровень доступа к данным)

public class PersonDAO { 
    public void savePerson(Person person) { 
     //logic to save the person in database or somewhere else 
    } 
} 

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

Примечание: Скелет веб-службы был адаптирован отсюда Creating a Simple Web Service and Client with JAX-WS.