목차
- 프로토콜
- db연결
Protocol
RAM은 1바이트가 겹겹이 쌓여있는 모습입니다.
CPU와 RAM은 서로 32비트, 64비트로 통신을 하는데 우리 컴퓨터를 보면
64비트 운영 체제, x64 기반 프로세서 이런 식으로 되어있는 것을 확인할 수 있습니다.
어떤 기반의 프로세서와 os에 따라서 램과 통신을 하는 비트 기반이 달라집니다.
프로그램도 동일한데요, 우리가 어떤 프로그램을 다운로드할 때 os나 몇 비트인지 항상 체크하고 다운로드하죠? 그게 바로 여기에 이유가 있습니다. 프로그램을 cpu가 다룰 때 기반이 되는 비트가 다르면 비효율적입니다. 64비트 cpu가 32비트 프로그램을 다운로드하면 문제가 됩니다. 반대의 경우도 마찬가지죠!
Spring에서 db와 연결하기 위해 위와 같은 기초 지식이 필요합니다.
HDD는 파인 시스템으로 일일이 전부 다 뒤져서(리더 reader가 돌아감 ) 파일을 찾습니다,
그러나 램은 그렇지 않고 곧바로 전류로 통신합니다. 전류로 통신하기 때문에 무척 빠릅니다.
그렇지만 HDD에도 DBS라는 정렬되어있는 데이터가 있는데요.
여기에 접근하기 위해서 dbms(마리아 DB)로 접근을 해야 합니다.
JSP는 jdbc를 요구를 하죠, 바로 여기(마리아 DB)에 접근하려는 Connection의 역할을 jdbc가 하기 때문입니다.
Spring에서 DB에 접근하기 위해서 Maven에 MariaDB driver를 추가해줍니다.Spring과 MariaDB 사이에서의 원활한 통신을 위해 추가해주는 것이죠. 여기서 통신은 Protocol입니다. 서로 약속한 통신규약이죠. Query 문 처리!
우리가 통신을 할 때, 소켓 통신 또는 포트 통신으로 나누어집니다.
Protocol과 Interface의 뜻은 동일하게 약속이지만, 프로그래밍에서 살짝 다르게 쓰입니다.
Protocol은 통신 규약입니다. 우리가 어떻게 통신을 할지 약속을 정해 놓은 것입니다. 각자 대등한 관계에서의 약속이죠!
(서로 합의를 보는 것)
다만, Interface는 사용자 편의에 맞게 생산자가 직접 설계를 하는 것입니다. 약속이지만 다른 약속이죠.
프로토콜이 생긴 이유!
대학에서 교수님들끼리 논문 교류를 하기 위해서 작게 시작한 네트워크가, 다른 대학들도 서로 정보 교류를 하고 싶어서 작은 네트워크가 커지기 시작합니다. 연결을 할 때 서로 약속을 정하는 거죠! 이것이 Protocol이 생겨난 이유입니다. 각자의 내부 Protocol이 다르기 때문에, 다른 외부와는 연결이 힘들죠, 그렇지만 RFC라는 국제 Protocol의 표준을 만들어서 외부 Protocol을 통일을 시켜, 외부 통신을 원활하게 합니다.
마치 이런 것이죠!
우리와 연결을 하려면 약속을 지켜!
그렇게 하기 싫으면 말든가~
만약 프로토콜이 없으면 서로 통신을 이해하지 못해 뭘 할지 모릅니다!!
쿼리에서
Select 로드해서 모니터에 로드 ( 메모리에 로드 )
Insert 할 때 하드에 바로 기록하지 않고
기록하겠다는 로고가 먼저 남고
커밋(영구히 기록하다)을 먼저 해야지 Insert 됩니다.
Protocol이 없으면 이걸 어떻게 할지 모르기 때문에 Driver를 추가해서 프로토콜을 추가해줘야 합니다.!!!
( select 해서 결과를 리턴하는 것도 protocol이 하는 것임)
이 Protocol을 추가해주는 것도 Driver가 해줌 ( 원활한 통신을 도와줌 )
*
/starting new springboot/ 시에
Spring web을 추가를 안 하면 mvc를 못씁니다.
Spring web Devtool 이 없으면 코드를 확인할 때 서버를 항상 껐다 켜야 합니다.
필수적인 두 가지를 추가하지 않으면 불편합니다.
heidiSQL => DB 연결하는 툴
*
db연결
DB에 연결하기 위해 설치하고 실행합니다.
세션이 생겼다는 것은 요청하는 사람이 접근하는 것을 허용했다는 것입니다.
예를 들면
우리가 보통 음식점에 누가 문을 두드렸을 때
손님 (아이디, 비번)이 확인되면 문을 열어줍니다.
(세션이 생김)
*
계층도 있다?
5 계층이 세션 계층이다
세션 dbms 시스템에 맘대로 왔다 갔다 하려고 만듦
*
다른 예시로는
집에 친구가 놀러 왔는데 사람이 없어요, 근데 집주인 입장에서 진짜로 그 친구가 맞고 왔어요.
안에 누군가 있어야 문을 열어 줄 수 있습니다.
(리스너를 가짐-> 눈을 동그랗게 뜨고 기다림(보초))
데몬( 스프링 서버 )-> 버튼 누를 때까지
리스너가 있어야 됨
모든 포트 앞에는 리스너가 있어야 함!
리스너 – 소켓통신에서 나옴
어셉트 -> 너 받을게
블락당할 때까지 계속 백그라운드에서 돌고 있습니다.
스레드가 리스너 만들며
*
tips
타임 슬래쉬 리스너 계속 돔
서버 지할일하고 리스너도 계속 돔(문맥 교환)
*
리스너가 계속 돌아야 함!!
*
스레드 계속 만들다가 통신이 끝나면 걔 꺼를 날려버린다
10명이 들어오면 12개의 스레드
Cpu의 노는 시간을 줄이기 위해서
소켓 프로그래밍 개념임
*
프로그래밍하다가 리스너 오류 뜨면 마리아 DB를 켜자
로컬 호스트를 적으면 같은 호스트로만 접근함
‘%’를 적으면 미국에서도 접근할 수도 있음!!!!!!!! -> 회사에서는 내부 ip를 쓰자
*
CREATE USER 'korea'@'%' IDENTIFIED BY 'korea1234';
GRANT ALL PRIVILEGES ON *.* TO 'korea'@'%';
CREATE DATABASE koreadb;
*
-Query문 해석-
Korea 유저를 만들고
% -> 어디서 접근 가능한 (korea)
Korea1234 -> 비번
*.* -> 모든 권한을 다 주겠다! 누구에게? TO 'korea'@'%';
Koreadb라는 데이터베이스를 만들어!
readme에 넣어서 집에서도 똑같이 쓰자~
전체 쿼리를 실행하면 어디서 오류가 나오는지 모르기 때문에 현재 쿼리를 실행해서 확인해 보자.
현재 쿼리를 실행하면 한 줄씩 실행되며 ; 까지 실행하게 됨
md 마크다운 – 공부에 20분 걸림
``` sql -> 확장자명인 것들을 넣음
```
Readme를 나중에 GitHub에 올릴 수 있습니다
*
깃 헙은 명령어로 배워야 함
나중에 배포할 때 리눅스도 건드려야 함
*
아래에 사진처럼 application.properties의 확장자를 yml로 바꿉니다.
yml파일은 현존하는 중간(단)계 언어입니다, 가장 가볍습니다.
*
일명 야물 파일 임
*
*
경로는 알아놓으면 좋음! ViewResolver, TomcatLiberary 설치하면 웹앱 뒤에 넣어줘야 함! 그게 규칙임
*
Tips
자동 정렬 Ctrl + Sftit + F
마리아 DB를 연결해주는 jdbc.driver 추가
*
배울 때는 똑같이 해야 한다!
문서로 볼 때 똑같이 해본다 그래야 내 것 이 됨
*
MariaDB와 MySQL이랑 똑같은 Protocol을 씀
본인의 이름과 주소 url를 입력해주세요
하고 실행하면 연결됩니다.
*
JSP에서는 테이블의 정보를 받으려고 하면 결과를 받는 게 아니라
메모리에 떠있으며 메모리 커서를 받습니다!!
Rs.next(); 한 놈을 읽어서 자바 오브젝트로 넣습니다.
커서로 해놓고 그 테이블이면 user 객체(모델)에 컬렉션 리스트로 관리를 하는 것이 좋음
*
JPA를 써보자
JPA 이걸 쓰면 바로 객체를 만들어준다고??
-배민에서 사용함
오브젝트 릴레이션 맵핑
Object relation mapping
지금은 새로 테이블을 만들어야 하기 때문에 create를 선택합니다.
도메인은 범주가 있다는 뜻
자바 패키지 – 자바 소스파일 묶음
서비스를 만들 때 도메인별로 나눠서 만들면 편합니다.
관리하고 싶은 테이블을 만들고 그 테이블에 해당하는 도메인을 만들면 됩니다.
*
도메인은 테이블을 가지고 가면 됨
User 도메인 , Product 도메인
섞으면 서비스가 나옴!
도메인 = 범주
패키지를 만들 때의 규칙
도메인 만들 때 규칙
*
1. 테이블을 먼저 만들고
2. 모델링(그 세상에 맞게 변환시킴 DB-> JAVA Object)을 합니다.
3. Java class를 만듦
*
Care는 프라이머리 키로 > 예전엔 주민번호 그러나 이제 바뀜 숫자로 씀 번호
*
아래 사진처럼
전략이 다 다릅니다.
Identity로 선택하면 Oracle이던 MySQL이던 다 알아서 맞춰줍니다.
이제 실행시키고 확인해보면 HeidiSQL에 koreadb와 안에 user가 만들어진다.
Tips
아래 것들은 수업시간에 필기한 것들입니다.
RFC 잘 기억해 두자!
프로토콜만 공부하면 됨
함수는 공부 x
쓰면 되겠네 접근
함수도 종류 많지 않음
램은 용량이 많이 안됨, 그래서 dbs에 저장
램에 있으면 빠르게 캐치 없으면
램은 전류로 찾지만
하드는 물리적으로 찾음
dbs에 있는 건 램에 넘겨줌
페이지 교체-> 램 용량을 모를 때
Cpu가 멈춤 램 교체 시간에(아무 일도 없음)
멍 때릴 시간을 줄여야 함
쇼핑몰을 한다면 통계를 내서 새벽에 서버 업데이트를 함
통계 데이터가 적제 하게 됨
현대
프로그래밍에서 젤 중요한 거
IO를 줄여야 함 -> 알고리즘을 오지게 잘 짜야함
빅데이터는 연산만 안 함
이런 거 말고
메모리에 있는 걸 cpu가 좋아함
그러나 알고리즘은 생각보다 안중 요함
Ram -> DBS로 접근하지 않게 프로그램을 짜야함
(데이터 구조화)
(젤 많이 쓰는 기능을 염두에 두고 개발해야 함)
(환불을 많이 하네! -> 이 걸 처리해야 함
개발자는 문법 배우고 이러지만
회사 가도 기술 배움
좋은 프로그래머는 비즈니스 로직을 잘 짜야함 (업무 프로세스)
현직에서의 시스템을 알아야 함(비즈니스를 잘 알아함)
기술만 할래 -> 연구/논문
내가 캠핑 시스템-> 캠핑 시스템을 다 알아야 함
좋은 프로그래머 = 비즈니스 로직 + 기술
회계프로그램 = 회계지식 + 프로그래밍 기술
끝까지 가면 아키텍처가 됨
많은 서비스가 있는데 기획,
다 다르다 -> 이런 걸 서비스라고 한다
'BackEnd > Spring' 카테고리의 다른 글
[Spring][6]Desigin of RestfulAPI/UPDATE in CRUD[RestfulAPI와 업데이트 실습] (0) | 2021.07.01 |
---|---|
[Spring][5]TCP/JPARepository for CRUD[TCP통신과 JPA를 이용한 Repository 설계] (0) | 2021.06.30 |
[Spring][3]Dependency Injection[의존성 주입] (0) | 2021.06.28 |
[Spring][2] The practice of MVC pattern [MVC 패턴 실습] (0) | 2021.06.24 |
[Spring][1] MVC pattern [MVC 패턴] (0) | 2021.06.24 |