우선 프레임워크가 무엇인지 알고가자!

Framework 란?

프레임워크는 말그대로 뼈대이다.

뼈대의 의미를 소프트웨어적인 관전에서 보면

아키텍쳐에 해당하는 골격 코드이다. 

(골격코드란? - 프로그램의 골자만 기술한 불완전한 형식의 명령어, 명령아가 사용될 때마다 완전하게 또는 상세히 지정해야만 한다.)

특정한 목적에 맞게 프로그래밍을 쉽게 하기 위한 약속.

모든 프레임워크는 어떤 언어를 기반으로, 어떠한 목적을 갖고 만들어졌다.

가장 헷갈려 하는 게 라이브러리 인데, 라이브러리는 우리가 직접 클래스를 new로 생성해서 사용하는 것이라고 보면 되고,

프레임워크는 내가 만든걸 framework가 사용해주는 것을 말한다.

이런 걸 제어의 역전(Inversion of Control), 뒤집혀진 라이브러리라고 한다.

개발자 입장에서 프레임워크를 본다면, 

다른 개발자 2명이 서로 다른 기술과 경험으로 코드를 작성한다고 해보자,

그리고 프로젝트가 끝나면 다른 사람이 프로젝트에 대해 유지보수를 할 수 있는데

2명 다 코드가 전혀 다르기 때문에 유지보수 하기가 힘들다.

근데 이때, 만약 뼈대(골격)가 같다면

각기 다른 자유분방한 코드보다는 유지보수가 수월할 것이다.

이러한 이유로 프레임워크가 탄생하게 되었다.

등장배경을 간략히 말하자면, EJB(엔터프라이즈 자바빈즈(Enterprise JavaBeans; EJB)는 기업환경의 시스템을 구현하기 위한 서버측 컴포넌트 모델이다. 즉, EJB는 애플리케이션의 업무 로직을 가지고 있는 서버 애플리케이션이다. EJB 사양은 Java EE의 자바 API 중 하나로, 주로 웹 시스템에서 JSP는 화면 로직을 처리하고, EJB는 업무 로직을 처리하는 역할을 한다.)가 전에 개발자들이 사용하던 서버 애플리케이션이었는데 고가의 장비(WAS 등등)이 필요했고, 개발환경 설정 그리고 테스트 환경에 많은 애로사항이 있어서 훨씬 가볍게 애플리케이션을 개발할 수 있는 프레임워크인 Spring이 등장했다고 합니다. EJB에 비해 톰캣 컨테이너를 사용하고, 코드의 경량화 그리고 개발 중 테스트가 쉽다는 장점이 있습니다.

EJB에서 선언적 트랜잭션(자동적으로 예외처리, 커밋을 해주는 것이라고 생각하면 된다.), 분산 컴포넌트(Enterprise Component)라는 좋은 특징을 갖고 있었지만, 위에서 말한 것과 같이 어렵고 무겁고 테스트도 안되고 그랬는데, Spring에서 EJB의 좋은 특징을 갖고 단점을 줄여서 개발자들의 봄이 왔다고 해서 이름도 Spring이라고 지었다고 합니다. 

* 스프링프레임워크의 장단점 ?

프레임워크 장점

- 정형화 되어있어서 일정수준의 품질을 기대할 수 있고, 

유지보수가 쉽다. (프레임워크 숙달자 기준) 등

프레임워크 단점

- 습득시 노력과 시간이 필요하다. 

- 무겁다 등

스프링 장점 (다른 프레임워크에 비교)

- 개발자가 기본적인 디자인 패턴 (DI, AOP, 서비스 추상화 등)을 강제적으로 사용하도록 한다.

- 유연성이 좋다. 등

- 각 모듈을 조립(설정만 완벽하게 하면)하면 기능을 쉽게 구현가능하다.

- 모듈(기능) 추가및 제거 - 관리가 수월하다. 

스프링 단점

- 습득시간이 오래 걸린다.

- 무겁다. model 1 방식 개발방식에 비해서 상대적으로?

- 스프링 설정하는 것에만 익숙해지다보니 코딩 실력이 떨어지게됨. 

(스프링이 구현해 놓은걸 직접 구현하면서 코딩실력을 늘릴수 있는데 그렇게 못해서..)

출처 

alsyean.tistory.com/23

coneseo.tistory.com/31
https://keehyun2.tistory.com/entry/스프링-프레임워크-장단점-분석 [khp blog]

JSP란 무엇일까?

Java Server Pages의 약자이며,

HTML 코드에 자바 코드를 넣어 동적웹페이지를 생성하는 웹어플리케이션 도구이다.

JSP가 실행되면 자바 서블릿(Servlet)으로 변화되며 웹 어플리케이션 서버에서 동작되면서 필요한 기능을 수행하고

그렇게 생성된 데이터를 웹페이지와 함께 클라이언트로 응답한다.

위와 같이 정의만 보고는 이해하기가 쉽지 않기 때문에 몇가지 개념을 알고 가자!

• 웹
• 웹 어플리케이션
• 자바 서블릿
• JSP 와 서블릿

웹(Web)

웹이란 인터넷 기반의 정보기술로 World Wid Web의 줄입말로 쓰이며 WWW 라고도 한다.

전세계에 거대한 네트워크 망을 통해 정보를 공부하며 정보의 흐름은 양방향성을 가진다.

웹 어플리케이션(Web Application)

웹 어플리케이션은 웹에서 실행되는 응용프로그램을 뜻하며 인터넷을 통한 은행업무, 인터넷쇼핑 등등 인터넷에서 하는 여러 서비스를 총칭하며 사용자가 필요한 요청(Request)를 하고 서버에서는 이에 해당하는 요청을 수행하고 그리고 요천한 데이터를 응답(Response)한다.

웹 어플리케이션이 위와 같이 동작하기 위한 몇가지 구성요소가 있다.

웹 브라우저(Web Browser) : 클라이언트에서 요청을 하고 전달받은 페이지를 볼수있는 환경을 말한다.  ( 크롬, IE, Safari, Firefox 등.. )

웹 서버(Web Server)  : 클라이언트로 부터 요청받아 서버에 저장된 리소스를 클라이언트 에게 전달한다. 주로 정적컨텐츠롤 담당한다.

웹 어플리케이션 서버 ( Web Application Server ) : 줄여서 was 라고도 부르며 서버단에서 필요한 기능을 수행하고 그결과를 웹서버에게 전달한다.

데이터베이스 : 서비스에 필요한 데이터를 보관, 갱신 등 관리를 한다.

자바 서블릿(Java Servlet)

서블릿이란 웹페이지를 동적으로 생성하기 위해 서버측 프로그램을 말한다.

이는 자바 언어를 기반으로 만들어지며 웹 어플리케이션 서버(Web Application Server) 위에서 컴파일 되고 동작한다.

JSP 와 서블릿

JSP 와 서블릿의 차이점은 결과적으로 하는 일은 동일하지만

JSP 는 HTML 내부에 JAVA 소스코드가 들어감으로 인해 HTML 코드를 작성하기 간편하다는 장점이 있으며

서블릿은 자바 코드내에 HTML 코드가 있어서 읽고 쓰기가 굉장히 불편하기 때문에 작업의 효율성이 떨어진다. 

하지만 웹을 공부할때 JSP 와 서블릿은 함께 배운다,

그건 왜 때문일까..?

JSP 로 작선된 프로그램은 서버로 요청시 서블릿(Servlet) 파일로 변환되어 JSP 태그를 분해하고 추출하여 다시 순수한 HTML를 변환한다.

(출처: https://javacpro.tistory.com/43 [버물리의 IT공부])

 아래 이미지 참고!(출처:velog.io/@dlsdk2526/JSP와-서블릿)

JSP 의 장단점 

풀네임 : Java Server Page

구현언어 : Java

오픈소스 : X

벤더 : 오라클 Oracle

프레임워크 : Spring

WAS : Tomcat

장점 : 객체지향 설계로 큰 프로젝트에서 강점을 보인다. 주축이 되는 강력한 프레임워크가 존재한다. 벤더가 거대 기업이고, 한국에서 굉장히 많이 쓰이고 있다.

단점 : 각종 모듈을 설치해야 해서 가벼운 프로젝트에 어울리지 않고, 프레임워크를 잘 사용하지 않으면 개발이 힘들 수 있다. 또한 2019년 부터 기업사용자는 비용이 발생한다는 공식적인 발표가 있다.

오늘은 프레임워크와 라이브러리의 차이점에 대해 알아보자!

일단 프레임워크와 라이브러리는 둘다 다른 누군가가 쓴 코드인데, 우리의 프로젝트를 위해서 가져다가 쓰는거야!

즉, 우리의 코딩 삶을 윤택하게 하기 위해서 가져다가 쓰는 것들

라이브러리, 프레임워크를 가르는 차이점은 아주 간단한 컨셉이야!

Who is controlling ??? 누가 누구를 컨트롤 하는가! 이다.

너가 코드를 컨트롤하는건지 vs 누군가의 규칙을 따라 코딩하는건지

예를 들어, 라이브러리의 가장 좋은 예시는 JQuery 야! 제이쿼리는 웹사이트에 인터렉티브한 요소를 넣을 수 있는데 그래서 내가 웹사이트를 코딩을 하고 있는데 내가 필요할때, "내가" 제이쿼리를 소환을 해.

코딩을 하다가 필요할때 제이쿼릐를 부르는 거고, "내가"(나자신) 코딩을 해나가는 거지. 이게 라이브러리야! (우리가 필요할때 라이브러리를 쓰는거야. 그리고 라이브러리는 정말 쉽게 대체될 수 있어 = 내가 원하면 제이쿼리를 다른걸로 대체해도 돼! 그런다고 프로젝트가 망가지지도 않아, 왜냐면 시간절약하려고 소환하는 그런거니깐)

자. 하지만! 프레임워크는 달라! 왜냐 너가 프레임워크를 부르는 것이 아니거등! "프레임워크"가 너를 부르는 거지!

바로 이게 가장 명확한 라이브러리와 프레임워크의 차이점이야!

프레임워크로 일을 할때는 프레임워크의 규칙을 따라야해! 너가 코드의 규칙을 결정하는 입장이 아니거든! 

프레임워크가 어떻게 하라고 알려주는 거야! 프레임워크가 어디에 코드를 넣어야하는지 등등을 알려줘!

즉, 프레임워크가 너에게 규칙을 알려주는 거야! 어디에 템플릿을 넣고, 컨트롤러를 넣고, 뷰를 넣고..... 규칙에 따라서 하면 모든건 정상작동하겠지. 너가 컨트롤 하는건 없어. 그냥 규칙을 따라갈뿐.

프레임워크의 좋은 예시는 장고 웹 프레임워크임(django). 장고 웹 프레임워크는 규칙이  정말 많아. 잘 작동하기를 바란다면, 모든 규칙을 잘 준수해야하지.

예를 들어, 장고에서 어디민 패널을 만들고 싶다면, 무조건 코드를 admin.py에 써야해.

만약 URL을 바꾸고 싶다면? 반드시 파일명 url.py를 가야하듯이!

왜냐면 장고가 시작할때 url.py. admin.py를 읽거든.

너가 이걸 바꿀수는 없어. 이건 장고가 갖고있는 규칙이야. 이걸 잘 준수해야 어드민 패널, URL이 잘 작동하는걸 볼 수 있엉.

다시말해, 이 시나리오에서는 내가 장고를 부르고 그런거 없음. 장고 문서를 보면서 장고 규칙에 따라 코드들을 잘 넣어두면, 장고가 그걸 실행시키는 거니깐.

프레임워크라고 하는 것들은 반드시 따라야 하는 규칙이 있어.

라이브러리는 우리가 필요할때 부르는 것들인거고!

-> "내가" 라이브러리를 부르는 것이고 / "프레임워크"가 나를 부르는 거야!

그러니깐 "000을 빌드하기 위한 000 라이브러리"이면 너가 필요할때마다 부를 수 있는 것이라는 걸 알거야! (ex. A JavaScript library for builing user interfaces)

반대로 "000을 빌드하기 위한 프레임워크"이면 이건 규칙과 문서가 따라오는 것이며. 너가 적극 수용해야해. (ex. The Web framework for perferctionists with deadlines)

그런데 말이지! 리액트JS 웹사이트에 가면... "리액트는 라이브러리라고" 말을 해. 즉. 너의 어플리케이션의 UI를 빌드할때 리액트를 부르는거야. 이 경우 "너가" 리액트를 부르는 거지. 너가 부르는 것이니까. 리액트는 라이브러리가 되는 것이 맞지. 그리고 리액트는 그런 규칙,, 폴더 구조나 컴포넌트명이나, 그런게 없어. 하지만, "리액트가" 우리의 컴포넌트를 부르긴 하지. 그래서 이 경우엔 리액트를 프레임워크로 부를 수 있는 거야. 왜냐하면 리액트가 컴포넌트를 부르는거니깐. 규칙을 알려주고 말이지. 뭐가 틀리고, 뭐가 맞는지를 알려주거든. 너가 컴포넌트를 쓰면, 리액트가 그걸 불러와서 스크린에 보여줘! 그래서 꽤나 회색의 영역이고 관려하여 많은 구글 검색이 가능할거야!

어떤 사람들은 리액트는 라이브러리다. 너가 필요할때 부르니깐. 동시에 프레임워크로 불릴 수 있다. 컴포넌트를 불러오니깐~

리액트가 우리의 컴포넌트를 인터렉티브하게 만들어주니까! 리액트가 states. props 같은 걸 컴포넌트에게 주니까.

이건 Vue.js도 마찬가지야!

그런데 이게 라이브러리인지 프레임워크인지 규정하는게 중요한가?

나는 상관없다고 보는게. 프론트엔드에서 뭐든 다 이모양이거든(모르겠다.. 몰랐겠지.. 몰랐더라도... 몰랄겠구나... 모를수록... 몰랐으니)ㅋㅋㅋㅋㅋㅋ 하지만 적어도. 우리는 개념상으로는 이해하고 있어야 된다고 생각해! 이 둘의 차이가 무엇인지 말야.

즉. 둘의 경계가 항상 뚜렷하지는 않지만, 최소한의 프레임워크와 라이브러리의 개념 차이는 알고있자!

https://youtu.be/t9ccIykXTCM

DI(의존성 주입)를 해야하는 이유는 ?

DI로 프로그램을 설계 했을 때, 다음과 같은 이점을 얻을 수 있습니다.

• Unit Test가 용이해진다.
• 코드의 재활용성을 높여준다.
• 객체 간의 의존성(종속성)을 줄이거나 없엘 수 있다.
• 객체 간의 결합도이 낮추면서 유연한 코드를 작성할 수 있다.

즉, 한 클래스를 수정하였을 때, 다른 클래스도 수정해야 하는 상황을 막아줄 수 있습니다.

※ DI, 의존성 주입은 필요한 객체를 직접 생성하는 것이 아닌 외부로 부터 필요한 객체를 받아서 사용하는 것이다. 이를 통해 객체간의 결합도를 줄이고 코드의 재활용성을 높여준다.

오늘은 관심사 분리에 대해 공부해보자!

* 관심사 분리란 ??

- 소프트웨어 상에서 구조를 패턴, 역할, 기능 등 각각 맞게 섹션 별로 분리해서 작성하는 것을 말합니다. 이때 주의 사항은 분리를 해서 작성을 했을시, 그 특성에 맞게 하나의 역할을 부여해서 작성해야 하는 것입니다. 즉, 코드를 작성할때 '관심사의 분리'란 하나의 역할 별로 분리를 해서 작성하는 것을 말합니다.

쉽게 말해! 치료는 의사에게, 주사는 간호사에게, 약은 약사에게 처럼 목적에 맞게 또는 상황에 맞게 역할을 분리해주는 것입니다.