MVC
Mvc 개념 : M: 모델(model), V: 뷰(view), C: 컨트롤러(controller)
계층 구조 개념
뷰 계층: 데이터를 표시하고 사용자와 상호 작용하는 데 사용되는 인터페이스
제어 계층: 클라이언트 요청을 수신할 수 있음 특정 비즈니스 기능을 완료하려면 여전히 모델 구성 요소가 필요합니다.
모델 계층: 비즈니스 논리 및 데이터베이스 상호 작용을 처리하고 데이터를 운반하는 역할을 담당합니다. 간단한 pojo/vo(값 개체), 비즈니스 모델 구성 요소, 데이터 액세스 계층 구성 요소 등 다양한 유형의 모델이 있습니다.
모델 레이어 카테고리:
1) pojo/vo: 값 객체: 과일 클래스는 값 객체이며 해당 속성 데이터를 얻을 수 있습니다.
2) DAO: Data Access Object: 데이터베이스에 연결하여 해당 데이터베이스 형태를 운용하는 DAO 클래스
3) BO: 비즈니스 객체: 비즈니스 객체는 해당 데이터 객체를 호출하여 일련의 작업을 수행합니다.
비즈니스 객체와 데이터 액세스 객체 구별:
1) DAO의 메소드는 모두 단정밀도 메소드 또는 세분화된 메소드입니다. 각 메소드는 다른 작업의 영향을 고려하지 않고 데이터베이스 추가, 삽입 등 하나의 작업만 고려합니다. .
2) BO의 방법은 비즈니스 방법에 속하며, 실제 업무는 상대적으로 복잡하므로 비즈니스 방법의 세분성이 상대적으로 거칠다. 서비스 레이어의 비즈니스 구현에는 특히 정의된 dao 레이어 인터페이스 호출이 필요합니다. 서비스 레이어 비즈니스 로직을 캡슐화하는 것은 일반 비즈니스 로직의 독립성과 재사용성에 도움이 됩니다. 프로그램은 매우 간단한 것 같습니다.
예를 들어 계정 등록 기능은 비즈니스 기능이므로 등록 방법도 비즈니스 방법입니다.
그러면 이 비즈니스 메서드에는 많은 DAO 메서드가 포함되어 있습니다. 즉, 등록 기능을 완료하려면 여러 DAO 메서드의 조합을 통해 이 비즈니스 기능을 등록해야 한다는 의미입니다.
등록:
1. 사용자 이름이 등록되었는지 확인 - DAO에서 작업 선택
2. 사용자 테이블에 새 사용자 레코드 추가 - DAO에서 작업 삽입
3. 사용자 테이블에 새 사용자 레코드 추가 - DAO에서 작업 삽입
4. 시스템 메시지 테이블에 새 사용자 레코드를 추가합니다 - DAO
5의 삽입 작업. 시스템 로그 테이블에 새 사용자 레코드를 추가합니다 - DAO
6의 삽입 작업입니다. . .
간단히 말해서 DAO 계층은 데이터베이스를 처리하고 서비스 계층은 일부 비즈니스 프로세스(DAO 호출 작업뿐만 아니라)를 처리합니다.
MVC 구축의 장점
각 레이어를 강제로 분리할 수 있어 레이어 간의 의존성이 줄어들어 코드 재사용이 극대화될 수 있습니다. 예를 들어 MVC 계층에서는 여러 뷰가 하나의 모델을 공유할 수 있고 컨트롤러는 서로 다른 모델과 뷰를 연결하여 사용자 요구를 완성할 수 있습니다. 세 구성 요소가 서로 독립적이라는 이 디자인 아이디어는 좋은 느슨한 결합을 만들 수 있습니다.
과일 프로젝트 시스템에 비즈니스 레이어 구현 개념 추가
원래의 최적화된 과일 시스템에서 사용자가 보낸 요청의 처리 흐름은 아래 그림과 같습니다:
요청을 받은 후 사용자 중앙 컨트롤러는 제어 계층에 직접 명령을 내립니다. 제어 계층은 모델에 액세스하여 일련의 작업을 수행합니다. 데이터를 얻기 위한 DAO 메서드 호출 마지막으로 페이지 렌더링을 봅니다.
MVC 모델을 이용하여 개발하다 보면 시간이 지나면서 점차 레이어 간의 접착성과 모호함을 느끼게 되는데, 이것이 서비스 레이어 등장의 중요한 이유입니다. 비즈니스 로직은 C 레이어와 M 레이어로 연결되어 있으므로 비즈니스 로직을 분리하여 독립적인 서비스 레이어로 만들어야 합니다.
이 기능을 수행하기 위해 사용자 테이블과 권한 테이블을 사용할 것이라고 가정하면 첫 페이지에서 작업에 액세스하고 작업이 사용자 모듈 서비스를 호출합니다. 사용자 모듈 서비스는 사용자 테이블을 작동하는지 권한 테이블을 작동하는지 여부를 결정합니다. 사용자를 운영하는 경우 서비스 구현 클래스는 userDAO를 호출합니다. 권한 테이블이 작동 중이면 권한 DAO가 호출됩니다. 즉, DAO는 데이터베이스의 각 테이블과 일대일 대응을 해야 하지만 서비스는 그렇지 않습니다.
서비스 레이어가 없어서 발생하는 문제:
비즈니스 로직은 컨트롤 레이어에서만 직접 구현할 수 있으므로 여러 컨트롤러가 공통 비즈니스 로직을 공유할 수 없습니다. 비즈니스 로직을 업그레이드해야 하는 경우 소스 코드를 직접 수정해야 합니다. 호환성으로 인해 컨트롤러 코드가 복잡해집니다.
서비스 계층의 역할:
서비스는 하나 이상의 모델을 사용하여 작업을 수행하는 방법인 비즈니스 계층입니다.
1: 몇 가지 일반적인 비즈니스 로직을 캡슐화합니다.
2: 데이터 영역과 상호작용합니다.
3: 기타 요청: 원격 서비스 데이터 획득 등.
따라서 컨트롤러가 모델 구축 호출과 뷰 처리에 더 집중할 수 있도록 모델을 호출하는 비즈니스 모델을 구축하는 것이 필요합니다.
package com.ck.fruit.biz.impl;
import com.ck.dao.FruitDAO;
import com.ck.fruit.biz.FruitService;
import com.ck.fruit.pojo.Fruit;
import java.util.List;
public class FruitServiceImpl implements FruitService {
FruitDAO fruitDAO=null;
@Override
public List<Fruit> getFruitList(String keyword, Integer pageNo) {
return fruitDAO.getFruitList(keyword,pageNo);
}
@Override
public void addFruit(Fruit fruit) {
fruitDAO.addFruit(fruit);
}
@Override
public Fruit getFruitById(Integer fid) {
return fruitDAO.getFruitByFid(fid);
}
@Override
public void delFruit(Integer fid) {
fruitDAO.deleteFruit(fid);
}
@Override
public Integer getPageCount(String keyword) {
Integer fruitCount=fruitDAO.countNum(keyword);
Integer pageCount=(fruitCount+5-1)/5;
return pageCount;
}
@Override
public void updateFruit(Fruit fruit) {
fruitDAO.updateFruit(fruit);
}
}
위 모델을 구축한 후 컨트롤러에서 비즈니스 호출만 하면 되며, FruitDAO에서 직접 메소드를 호출할 필요가 없습니다.
서비스 계층은 DAO 계층 위에 구축되며, 서비스 계층은 DAO 계층이 구축된 후에만 구축될 수 있다. 서비스 계층은 컨트롤러 계층 아래에 있으므로, 서비스 계층은 DAO 계층의 인터페이스를 호출할 뿐만 아니라, 또한 중간 계층에 있는 호출을 수행하기 위해 컨트롤러 계층 클래스에 대한 인터페이스를 제공합니다. 각 모델에는 서비스 인터페이스가 있으며 각 인터페이스는 자체 비즈니스 처리 방법을 캡슐화합니다.
IOC
MVC 종합 디자인 패턴을 채택합니다. MVC 자체는 디자인 패턴의 한 유형이 아닙니다. 디커플링을 궁극적인 목표로 하는 구조를 설명합니다. 디커플링이란 특정 코드 계층을 변경해도 다른 코드 계층에는 영향을 미치지 않는다는 의미입니다. , Spring과 같은 프레임워크를 안다면 인터페이스 지향 프로그래밍을 이해할 것입니다. 프레젠테이션 계층은 컨트롤 계층을 호출하고 컨트롤 계층은 비즈니스 계층을 호출하며 비즈니스 계층은 데이터 액세스 계층을 호출합니다. 초기 단계에서는 새로운 객체를 사용하여 다음 레이어를 호출할 수도 있는데, 예를 들어 비즈니스 레이어에서 새로운 DAO 클래스 객체를 생성하고 DAO 클래스 메소드를 호출하여 데이터베이스에 접근하는 경우 비즈니스 레이어가 다음 레이어를 호출해야 하기 때문에 이는 잘못된 것입니다. 특정 객체를 포함하지 않으며, 참조만 있을 수 있으며, 특정 객체가 존재하면 결합됩니다. 따라서 레이어 간 디커플링을 달성해야 하며 IOC는 이러한 요구 사항을 달성할 수 있습니다.
개념적 이해
- Coupling/Dependency
의존성(Dependency)은 무엇인가가 무엇인가와 분리될 수 없다는 것을 의미하며,
소프트웨어 시스템에서는 계층들 사이에 의존성이 존재합니다. 우리는 이것을 커플링이라고도 부릅니다.
우리 시스템 아키텍처 또는 설계의 한 가지 원칙은 높은 응집력과 낮은 결합도입니다.
레이어 내 구성은 응집도가 높아야 하고, 레이어 간 관계는 낮은 결합이어야 하며, 이상적인 상황은 0 결합(즉, 결합이 없음)입니다. - IOC - Inversion of Control/DI - 종속성 주입
Inversion of Control:
1) 이전 프로젝트의 ControllerServlet에서 서비스 객체 FruitService Fruitservice=new FruitServiceImpl()을 생성했습니다.
서블릿의 메소드에 나타나면 다음과 같습니다. Fruitservice의 범위(라이프사이클)는 메소드 수준입니다.
서블릿 클래스에 나타나는 경우, 즉 FruitService가 멤버 변수인 경우 이 FruitService의 범위는 서블릿 인스턴스 수준입니다.
2) 이후 applicationContext.xml에 FruitService를 정의한 후 XML을 파싱하여 FruitService 인스턴스를 생성하고 이를 beanMap에 저장했는데, 이 beanMap은 beanFactory 클래스의 다른 클래스 인스턴스를 생성합니다. 따라서 기존 서비스 인스턴스, DAO 인스턴스 등의 Life Cycle을 이전(변경)하였습니다. 제어권은 프로그래머에서 BeanFactory로 이전됩니다. 이러한 현상을 제어 역전이라고 합니다.
종속성 주입:
1. 이전에는 제어 계층에 코드가 있었습니다: FruitService FruitService=new FruitServiceImpl(), 제어 계층과 서비스 계층 사이에 결합이 있습니다. 2. 그 후 코드를
FruitService FruitService=null로 수정했습니다. , 구성 파일 구성:
<bean id="fruit" class="com.ck.fruit.controllers.FruitController">
<property name="fruitService" ref="fruitService"/>
</bean>
이렇게 클래스에 필요한 종속성을 구성의 속성을 통해 찾아 인스턴스화하는 것이 주입 종속성입니다.
과일 프로젝트 시스템에 제어 반전 및 종속성 주입 추가
1. 원본 프로젝트에는 컨트롤러와 서비스 레이어에 다른 레이어를 인스턴스화한 후 호출하는 클래스가 있는데, 이런 방식으로 레이어 간 커플링 종속성이 존재하므로 현재 구조를 개선해야 합니다.
2. 필요한 클래스를 먼저 null로 지정
3. Beanfactory 인터페이스를 설정하고 구현 클래스를 생성하여 xml 구성 파일에 저장된 클래스 xml 구성 파일을 저장하기 위한 MAP 컬렉션을 빌드합니다.
각 Bean 노드는 각 클래스에 해당하며, Bean의 속성 노드는 Bean이 나타내는 클래스가 종속되어야 하는 클래스를 나타내며, 이는 후속 종속성 주입에 사용됩니다.
ClassPathXmlApplicationContext 클래스는 beanFactory 인터페이스를 구현하고 xml 구성 파일의 모든 클래스를 리플렉션을 통해 해당 컬렉션에 매핑합니다.
XML의 모든 클래스를 컬렉션에 주입한 후 Bean 간의 종속성 조립을 시작해야 합니다. Bean 아래의 속성 하위 노드를 가져와 컬렉션에서 해당 클래스 인스턴스를 가져온 다음 리플렉션 기술을 사용하여 속성을 추가합니다. 해당 클래스 할당, 종속성 주입.
마지막으로 과일 시스템을 실현합니다.
