4월 12 ~ 13일
MVC pattern
라우터가 분리 되어있음
model
엔티티, CRUD 메소드
view
React앱
controll
비즈니스 로직
ORM
object-realtional mapping
장점 mysql 없이 자바스크립트만으로 데이터베이스 이용가능
sequelize
한줄도 sql 문을 쓰지않고 CRUD를 다할수있음
Object 와 realtional data를 mapping
한 raw가 orm에서는 하나의 인스턴스와 취급이 되고있음
스키마는 결국 필드이름과 필드타입 컨스트레인트 각종제약 프라이머리키 같이
그 제약을 스키마에 포함하고있는데 그걸 객체지향형태 그걸 일일히 코드를 안쳐도 sequelize를 자동으로 만들어줌
많이 쓰는 typeorm - typescript와 많이 씀
sequelize 점유율이 높음
entity
쉽게말해서 스키마
고유한 정보의 단위
model
객체지향처럼 속성과 메소드가 포함되어있는데
특별히 데이터베이스에 있는 엔티티들을 가져와서 CRUD 메소드들을 추가한것
리디렉션
특정한 url을 다른곳으로 이동시켜주는것
migration
스키마 변경
마치 커밋로그로 생각하면된다 → 기록!
npx sequelize-cli db:migrate 이주
npx sequelize-cli db:migrate:undo 취소 (하나씩 없어짐)
(
1스키마 정말 많이 바꿈 ! → 게임을 만든다고 생각해볼시 갑자기 속성이 하나 추가됨 →
스키마 변경은 위험 → 로그를 적어놓을시 마이그레이션 사용하기도
스키마를 생성은 쉬운데 지우는건 어려움 왜? 스키마 이름을 바꾸면 클라이언트 다망가질수있음 → 이름바꾼거 다바꿔줘야됨..
스키마 작성시 필드명 변경이나 삭제는 실무에선 거의 없음
)
migration file vs model file
비슷해보이는 둘의 차이점
마이그레이션 - 직접 sql스키마에 영향
모델 - 모델단에서 visits에 값을 채워준다 → 둘다 해주면 좋다
sync = 코드와 스키마를 일치시켜준다
INSERT INTO → user.create
sequelize는 promise 기반의 Node.js ORM
findAll( ) 메소드는 SELECT * FROM과 같은 역할
개발 환경분리 이유 - > 테스트할때 데이터를 다 날려버릴수있기때문 → 야근각
(development , test 는 같이 사용하는경우도 있지만 production은 반드시 따로 )
환경 바꾸고싶을경우
($ export NODE_ENV=production)
개발환경에 따라서 데이터 타입이 다를수있다 → text, integer,string 으로 넣어두면 내가(mysql) 알아서 맞출게
더알아보기
-
자동으로 생성이 안될 수 있는지 파악해보기
-
Association 으로 JOIN table 구현해보기
HasOne : BelongsTo = 1:1
HasMany : BelongsTo = N:1
HasMany : BelongsToMany = N:N
-
Transaction
하나하나의 쿼리를 하나의 작업단위로보고 문제가생기면 롤백 성공했으면 커밋
-
소프트웨어 디자인 패턴 (mvc, closure, HOF, Flux, singleton , Client-Server)
파일을 왔다갔다 하는 것에 익숙해져야됨 → 레퍼런스나 다른사람들이 코드를 어떻게 짰는지 까보기
-
디자인패턴 관련 좋은 책들 (클린코드 , head first design patterns)
