Struts에서의 Model
Model Component는 중요한 소프트웨어의 산출물 입니다. 모델은 비즈니스 엔티티와 데이터 엔티티에 접근하고 수정할 수 있는 기능을 담당하는 규칙을 포함 합니다. 유효한 데이터의 관리와 재사용성을 위해 한곳에서 일관성 있게 관리하는 것이 좋습니다.
모델은 비즈니스 객체와 비즈니스 관련 규칙들을 접근하는데 사용되는 클라어언트의 타입과는 독립적으로 유지되어야 합니다. 그러므로 모델에서는 어떤 타입의 클라이언트나 프레임웍이 이 모델을 사용하는지에 대해 알아서는 안됩니다.
애플리케이션의 계층을 하부부터 네트웍계층, 퍼시스턴스 계층, 모델계층, 스트럿츠 프레임웍 계층, 클라이언트 계층으로 구분 한다고 할 때 의존성은 하위 구조와 연결되고 데이터는 상위 구조로 향한다. 즉 상위 계층은 하위 계층에 의존하지만 하위 계층은 상위 계층에 의존하지 않는다는 것을 명심해야 합니다.
만약 모델 계층에서 스프럿츠 프레임웍의 패키지나 클래스를 임포트 한다면 일단 이규칙을 위반 하는 것입니다. 즉 하위 계층이 상위 계층과 결합되어 있다면 유지보수, 재사용의 문제가 발생 할 수도 있습니다.
퍼시스턴스는 일반적으로 사용자가 다른 방법 등으로 애플리케이션에 입력하고 애플리케이션이 종료 되더라도 남아 있는 데이터를 말합니다.
----------------------
모델의 타입
----------------------
소프트웨어의 개발에서 모델은 엔티티에 대한 논리적인 표현과 프로그램에 사용 할 수 있는 클래스 및 인터페이스와 같은 자원을 이야기 하는데 요구분석이 끝나게 되면 개념 모델을 개발 하는 것입니다.
1. 개념 모델
개념모델은 사용자의 요구를 분석하는 동안 실생활의 Entity를 바탕으로 설계 되어야 합니다. 대부분 개념모델에서는 개념모델에 속한 속성을 표현하며 행위는 일반적으로 표현하지 않습니다.
예를 들면 고객, 주문, 상품카탈로그, 쇼핑카트, 이이템 등이 해당 됩니다.
2. 디자인 모델
개념모델을 만들었으면 적절한 디자인내용으로 채워야 하는데 일반적으로 클래스 다이어 그램, 관계 다이어그램, 상태 다이어그램을 주로 표현하며 최소한 한 개 이상의 클래스 다이어그램이 나와야 합니다.
앞에서 정의한 개념모델을 Business Object라는 이름으로 모델링 했습니다. CustomerBO, OrderBO, ItemBO등이 해당 됩니다.
---------------------
비즈니스 Object란
---------------------
비즈니스 객체는 실세계 Entity의 추상이며 사람, 장소, 물건, 비즈니스 영역의 개념등을 표현 합니다. 예를 들면 아이템, 주문, 고객등이 해당 됩니다.
비즈니스 객체는 상태와 행위로 구성되는데 그 예를보면 OraderBO 객체는 고객의 주문과 가격, 주문상태와 관련된 정보를 포함하며 이러한 정보를 제공하는 고객이 누구인지 알수 있게 해줍니다.
결국 비즈니스 객체(BO)를 구성하는 클래스들은 상태와 행위로 구성되며 사람, 장소, 물건, 비즈니스 영역의 개념들을 포함하며 재사용이 가능해야 합니다.
비즈니스 객체는 일반적으로 Entitiy Business Object, Process Business Object, Event Business Object와 같이 3개의 그룹으로 분류 할 수 있습니다. 이중에서 가장 흔하게 볼 수 있는 것은 Entity Bsiness Object인데 이것은 일반적으로 명사로 표현되는 고객, 주문, 아이템 등이며 EJB에서는 Entity Bean, 일반적인 웹애플리케이션에서는 비즈니스 애플리케잇ㄴ의 상태와 행위를 포함하는 일반적인 자바빈으로 모델링 합니다.
Process Business Object(프로세스BO)는 애플리케이션의 비즈니스 로직이나 워크플로우등을 나타내며 대부분 엔티티BO에 의존하여 비즈니스 영역에서 동사로 표시 됩니다. EJB에서는 세션빈이나 메시지 드리븐 빈으로 모델링 하며 다른 애플리케이션에서는 애플리케이션의 컨트롤러나 측정한 행위를 표현하는 일반적인 자바빈으로 표현 합니다.
Event Business Object(이벤트BO)의 경우 애플리케이션에서 발생 하거나 시스템의 다른 액션들이 발생 시키는 exception, alert, time out과 같은 이벤트를 표현 합니다.
비즈니스 객체는 대부분 인터페이스를 이용하여 내부를 숨기고 구현의 변화로부터 호출자를 보호 합니다. 예를 들어 비즈니스 객체에서 java.util.ArrayList를 java.util.List를 사용하여 표현 한다고 할 때 내부적으로 ArrayList를 LinkedList로 바꾼다고 해서 호출자는 아무런 영향을 받지 않습니다.
--------------------------------
비즈니스 객체의 Persistence
--------------------------------
애플리케이션이 객체를 메모리에 생성 후 종료 된다면 메모리의 객체도 소멸될 것 입니다. 결국 객체들은 소멸되거나 어디엔가 저장 되어야 합니다.만약 고객의 주문을 가지고 있는 주문BO가 사라지게 된다면 엉뚱한 일이 벌어 지겠죠…
데이터 퍼시스턴스에 저장을 해야 하는데 이를 위해 관계형 DB등이 이용 됩니다.
Struts에서의 Model
Model Component는 중요한 소프트웨어의 산출물 입니다. 모델은 비즈니스 엔티티와 데이터 엔티티에 접근하고 수정할 수 있는 기능을 담당하는 규칙을 포함 합니다. 유효한 데이터의 관리와 재사용성을 위해 한곳에서 일관성 있게 관리하는 것이 좋습니다.
모델은 비즈니스 객체와 비즈니스 관련 규칙들을 접근하는데 사용되는 클라어언트의 타입과는 독립적으로 유지되어야 합니다. 그러므로 모델에서는 어떤 타입의 클라이언트나 프레임웍이 이 모델을 사용하는지에 대해 알아서는 안됩니다.
애플리케이션의 계층을 하부부터 네트웍계층, 퍼시스턴스 계층, 모델계층, 스트럿츠 프레임웍 계층, 클라이언트 계층으로 구분 한다고 할 때 의존성은 하위 구조와 연결되고 데이터는 상위 구조로 향한다. 즉 상위 계층은 하위 계층에 의존하지만 하위 계층은 상위 계층에 의존하지 않는다는 것을 명심해야 합니다.
만약 모델 계층에서 스프럿츠 프레임웍의 패키지나 클래스를 임포트 한다면 일단 이규칙을 위반 하는 것입니다. 즉 하위 계층이 상위 계층과 결합되어 있다면 유지보수, 재사용의 문제가 발생 할 수도 있습니다.
퍼시스턴스는 일반적으로 사용자가 다른 방법 등으로 애플리케이션에 입력하고 애플리케이션이 종료 되더라도 남아 있는 데이터를 말합니다.
----------------------
모델의 타입
----------------------
소프트웨어의 개발에서 모델은 엔티티에 대한 논리적인 표현과 프로그램에 사용 할 수 있는 클래스 및 인터페이스와 같은 자원을 이야기 하는데 요구분석이 끝나게 되면 개념 모델을 개발 하는 것입니다.
1. 개념 모델
개념모델은 사용자의 요구를 분석하는 동안 실생활의 Entity를 바탕으로 설계 되어야 합니다. 대부분 개념모델에서는 개념모델에 속한 속성을 표현하며 행위는 일반적으로 표현하지 않습니다.
예를 들면 고객, 주문, 상품카탈로그, 쇼핑카트, 이이템 등이 해당 됩니다.
2. 디자인 모델
개념모델을 만들었으면 적절한 디자인내용으로 채워야 하는데 일반적으로 클래스 다이어 그램, 관계 다이어그램, 상태 다이어그램을 주로 표현하며 최소한 한 개 이상의 클래스 다이어그램이 나와야 합니다.
앞에서 정의한 개념모델을 Business Object라는 이름으로 모델링 했습니다. CustomerBO, OrderBO, ItemBO등이 해당 됩니다.
---------------------
비즈니스 Object란
---------------------
비즈니스 객체는 실세계 Entity의 추상이며 사람, 장소, 물건, 비즈니스 영역의 개념등을 표현 합니다. 예를 들면 아이템, 주문, 고객등이 해당 됩니다.
비즈니스 객체는 상태와 행위로 구성되는데 그 예를보면 OraderBO 객체는 고객의 주문과 가격, 주문상태와 관련된 정보를 포함하며 이러한 정보를 제공하는 고객이 누구인지 알수 있게 해줍니다.
결국 비즈니스 객체(BO)를 구성하는 클래스들은 상태와 행위로 구성되며 사람, 장소, 물건, 비즈니스 영역의 개념들을 포함하며 재사용이 가능해야 합니다.
비즈니스 객체는 일반적으로 Entitiy Business Object, Process Business Object, Event Business Object와 같이 3개의 그룹으로 분류 할 수 있습니다. 이중에서 가장 흔하게 볼 수 있는 것은 Entity Bsiness Object인데 이것은 일반적으로 명사로 표현되는 고객, 주문, 아이템 등이며 EJB에서는 Entity Bean, 일반적인 웹애플리케이션에서는 비즈니스 애플리케잇ㄴ의 상태와 행위를 포함하는 일반적인 자바빈으로 모델링 합니다.
Process Business Object(프로세스BO)는 애플리케이션의 비즈니스 로직이나 워크플로우등을 나타내며 대부분 엔티티BO에 의존하여 비즈니스 영역에서 동사로 표시 됩니다. EJB에서는 세션빈이나 메시지 드리븐 빈으로 모델링 하며 다른 애플리케이션에서는 애플리케이션의 컨트롤러나 측정한 행위를 표현하는 일반적인 자바빈으로 표현 합니다.
Event Business Object(이벤트BO)의 경우 애플리케이션에서 발생 하거나 시스템의 다른 액션들이 발생 시키는 exception, alert, time out과 같은 이벤트를 표현 합니다.
비즈니스 객체는 대부분 인터페이스를 이용하여 내부를 숨기고 구현의 변화로부터 호출자를 보호 합니다. 예를 들어 비즈니스 객체에서 java.util.ArrayList를 java.util.List를 사용하여 표현 한다고 할 때 내부적으로 ArrayList를 LinkedList로 바꾼다고 해서 호출자는 아무런 영향을 받지 않습니다.
--------------------------------
비즈니스 객체의 Persistence
--------------------------------
애플리케이션이 객체를 메모리에 생성 후 종료 된다면 메모리의 객체도 소멸될 것 입니다. 결국 객체들은 소멸되거나 어디엔가 저장 되어야 합니다.만약 고객의 주문을 가지고 있는 주문BO가 사라지게 된다면 엉뚱한 일이 벌어 지겠죠…
데이터 퍼시스턴스에 저장을 해야 하는데 이를 위해 관계형 DB등이 이용 됩니다.
댓글 없음:
댓글 쓰기