본문 바로가기

web +a

 (58)
도메인 설계 내용 (작성중) ∨ (참고) 실무에서 그리는 다이어그램 3가지 - 도메인 (협력, 역할, 책임) 관계 : 개발자가 아닌 기획자도 보고 이해 가능 - 클래스 다이어그램 : 개발자가 클래스(인터페이스)간 관계를 나타낸 것 (정적임) - 객체 다이어그램 : 서버가 실제로 사용하는 인스턴스끼리의 참조 (동적임) 개발자는 클래스 다이어그램 보고 구현해가면 된다. 회원도메인 설계 ∨ 요구사항 - 회원 가입 & 회원 조회 가능 - 등급 존재 : 일반, VIP - 회원 데이터는 미확정 : 자체 DB를 구축할 수도, 외부 시스템과 연동할 수도 더보기 다이어그램 ⓐ 회원 도메인 전체 관계 ⓑ 회원 도메인 클래스 다이어그램 ⓒ 회원 도메인 객체 다이어그램 더보기 도메인 구성 ∨ 회원 엔티티 - 회원 등급 - 회원 엔티티 ∨ 회원 저장소 -..
DIP, OCP 원칙이 깨지는 문제를 Spring으로 해결 요약 : 역할과 책임을 아주 잘 분리 & 다형성을 잘 이용하더라도 OCP, DIP 원칙을 깬다면 좋은 객체지향 설계가 아니다. 대표적 예시 : 순수 자바 코드 & new 연산자로 구현하는 아래 예시 해결법 : Spring DI - 그래서 DI컨테이너 원리를 직접 구현해볼 것임 - AppConfig를 통한 의존관계 주입 : 생성&주입을 서비스클래스가 직접 하지 않고 AppConfig가 하도록 분리한다. : 더이상 서비스클래스는 의존관계에 신경쓰지 않도록 구현하자. ● Spring 안쓰고 자바로 간단히 구현했을 때 문제점 어떤 문제가 생길까? ① 먼저, 회원 도메인에서 문제점을 찾아보자. * MemberServiceImpl은 private final MemberRepository 인스턴스 변수를 가지고 있는..
기본&중요 | SOLID 그리고 스프링 SRP 단일 책임 원칙 OCP 개방 폐쇄 원칙 ★ ∨ 확장에는 열려있으나 변경에는 닫혀있어야 한다. ㄴ 다형성(+인터페이스)를 이용하더라도 구현객체를 변경하려면 클라이언트 코드를 변경한다면 OCP가 깨지는 문제 발생 ㄴ 객체 생성 & 연관관계를 맺어주는 별도의 조립/설정자가 필요 => Spring DI/IoC컨테이너의 역할! (why? 이후에 이해하게 됨) LSP 리스코프 치환 원칙 ∨ 인터페이스의 규약은 지켜야 함 ISP 인터페이스 분리 원칙 ∨ 자동차 인터페이스 -> 운전/정비 인터페이스로 분리 => 사용자 클라이언트 -> 운전자/정비사 클라이언트로 분리 인터페이스가 명확해짐 & 적절히 대체하기 좋아짐 DIP 의존관계 역전 원칙 ★ ∨ 구현클래스(구현, 구체화)에 의존하지 말고 인터페이스(역할, 추상..
스프링&웹 | 스프링 DI (+ 계획 변경..!! ㅠㅅ ㅠ) 스프링의 코어는 DIxAOP 컨테이너이고, DI는 스프링 코어의 하나이다. DI 의미 dependancy injection : 객체를 직접 생성하는 것이 아닌, 외부에서 생성하여 주입시켜주는 방식이다. : 예를들면 new로 직접생성하지 않고, 외부에서 생성된 객체를 setter(), 생성자를 통해 사용하는 방식이다. : 스프링의 DI 컨테이너에서 객체를 생성하고, 필요한 곳에 객체를 주입시킬 수 있다. ∨ 의존 관계 주입? : 오브젝트 사이의 의존관계를 만드는 것임 : 어떤 오브젝트가 의존(이용)할 오브젝트를 주입(injection, 프로퍼티(인스턴스변수)에 설정)한다는 것임 ∨ 인터페이스를 이용해 부품화를 실현하는 것 : 인터페이스와 DI 컨테이너를 이용하여 제대로 '부품화'할 수 있다. ex) Pro..
스프링&웹 | 각 레이어에 관련된 스프링 기능 스프링은 애플리케이션 아키텍처의 기반이 된다. ∨ MVC 프레임워크 (스프링 MVC, 스프링 웹 플로) ∨ JDBC를 추상화한 프레임워크 (스프링 JDBC) ∨ 기존 프레임워크 => DIxAOP 컨테이너를 중심으로 통합 가능하다! . . 웹 애플리케이션의 각 레이어에는 어떤 스프링 기능이 해당하는지 알아보자. 프레젠테이션 층 ∨ 스프링 MVC : 스프링 MVC, 스프링 웹 플로 이용 가능 : 즉 MVC 프레임워크를 이용한다. cf) 스프링 웹 플로를 이용시 Ajax 연계 가능 ∨ 스프링 시큐리티 : 화면별 액세스 제어에 많이 사용된다. : 물론 레이어 전체에서 사용 가능하다. : 인증/인가 기능 제공 & 베이직 인증이나 OAuth 표준에 따라가는 인증서비스(페북, 트위터, 구글)를 사용 가능! 비즈니스 ..
스프링&웹 | 웹애플리케이션의 문제점 & 스프링의 해결 웹 애플리케이션이 안고 있는 문제점 => 스프링을 이용하지 않을때의 문제점 => 스프링 이용시 해결 가능한 것들! ● 오브젝트의 생명주기 문제 웹애플리케이션의 프레젠테이션 층에는 컨트롤러가 Servlet이다. (MVC2 모델 채용) (recall: 웹애플리케이션의 프레젠테이션 부분에서 UI, 컨트롤러를 담당) Servlet 특징 : View에 액세스하는 유저 증가시 인스턴스화 하는 것이 많아져 가비지컬렉션 성능저하와 메모리 압박을 받을 수 있어서 멀티스레드로 동작한다. 그러나 멀티스레드로 동작하더라도 언제든 그러한 문제점이 일어날 수 있다. 그래서 서비스 로직의 오브젝트를 싱글턴으로 구현해서 그러한 문제점을 방지할 수도 있지만, 이 또한 새로운 문제가 많다(65p 참고) 스프링은 이렇게 난감한 오브젝트의..
스프링&웹 | 기초 지식 2 - 레이어별 책임 [ intro ] 지난 시간 : 웹 애플리케이션 아키텍처를 간단히 공부했다. 그 중 웹 애플리케이션을 논리적으로 분류하는 레이어 개념을 새로 알았다. 이번에는 레이어별로 어떤 책임을 가져야 하는지 공부한다. 레이어를 나누는 방법은 경우마다 다르지만 크게 이렇게 분류하기로 했다. - 프레젠테이션 층 - 비즈니스로직 층 - 데이터액세스 층 대략적으로 각 레이어가 가져야 하는 역할, 책임, 설계지침을 알아보자. (표/도표는 스프링4 입문 책에 있는 내용임) 1. 프레젠테이션 층 ▶ 주 역할 : UI와 Contoller 제공 * UI 요즘에는 사용자의 요청이 많아지고 다양하게 발전하기 때문에 고정된 지침은 없다. 사용할 기술을 정했으면 그에 맞는 설계를 하면 된다. 참고) UI 구현 방법 예시 : 리액트, 앵귤..
스프링&웹 | 기초 지식 2 - 웹 애플리케이션 아키텍처 애플리케이션 아키텍처 Def : 애플리케이션 전체의 구조.. 공통된 매커니즘.. ex) 사용자 인터페이스 구조, DB접근방식, 시스템 기반 부분 cf) 스프링이 왜 웹 애플리케이션 개발에 필요한지 이해하기 위한 필수 기초지식 아키텍처 설계에는 두가지 목표설정이 반드시 필요 ⓐ 사용자의 요구를 만족시키자는 목표 - use case를 잘 규정하기 ⓑ 개발자나 운영자를 위한 목표 데이터 액세스 층 & 비즈니스 로직 층의 의존관계를 역전하면 => 비즈니스 로직 층이 데이터 액세스 층의 인터페이스를 소유하게 된다. ※ 중요한 쪽이 인터페이스를 소유한다는 원칙도 존재 (추후 부품화에서 배우겠다) 원칙 안정 의존 원칙 의존의 역전 상세 설계&구현은 스프링에 의존하는 부분이 많다 (나중에 학습) if 프레젠테이션 층 ..
다른 블로그

티스토리툴바