qwef

일단은 최상위 컴포넌트 const root = ReactDOM.createRoot(document.getElementById('root')); root.render( ); 얘는 저렇게 root에 직접 연결해서 render, #root에다 전해주는 애임. 여기다 필요한 거 불러다 쓰면 됨. 그 다음, 컴포넌트는 2가지 스타일이 있음. 함수형 import './main.css'; function Main(){ return ( Hello React V18 ) } export default Main; css import 하는 건 일단 무시하고, 저렇게 function 컴포넌트명(){ return( 요소 ) } export default 내보낼것 return 안에다 요소를 쓰면 됨. 내보낼 것은 지금같은 경우 저..

{ "name": "test_react", "version": "0.1.0", "private": true, "dependencies": { "@testing-library/jest-dom": "^5.17.0", "@testing-library/react": "^13.4.0", "@testing-library/user-event": "^13.5.0", "react": "^18.2.0", "react-dom": "^18.2.0", "react-scripts": "5.0.1", "web-vitals": "^2.1.4" }, "scripts": { "start": "react-scripts start", "build": "react-scripts build", "test": "react-scripts test..

리액트는 설치할 때 npx를 씀 npx create-react-app . 이렇게 하면 현재 폴더에 react 환경을 만듦. npx는 create-react-app 이라는 명령어가 따로 있을 정도로 react랑 연관관계가 깊나 봄. 여튼 그럼 이제 설치 됨. src에 index.js가 index.html과 비슷한가 봄. 단, react는 html, js 한 곳에 모여있음.

JPA입장에서는, 연관관계의 주인에게만 값을 넣어주면 되지만, 사실 객체지향 입장에서는 둘 다 넣어줘야 한다. Team team = new Team(); team.setName("TeamA"); em.persist(team); Member member = new Member(); member.setName("member1"); member.setTeam(team); em.persist(member); tx.commit(); 여기서 보면, DB상으로는 문제가 없다. Team 생성한 다음에, persist 해서 id까지 완벽히 넣고 영속성 컨텍스트에 까지 넣고, Member를 만들어 그 만든 team을 넣어주고, Member도 마찬가지로 영속성 컨텍스트에 넣어준다. DB상으로는 제대로 반영이 되었다. 근데,..

보호되어 있는 글입니다.

양방향 연관관계 Member의 team과 Team의 members 처럼 양쪽 둘다 가지고 있는. 일단 테이블 연관관계는 바뀐 게 없다. 생각해보면, member에서 팀을 알고 싶으면 team의 team_id를 기준으로 조회해보면 되고, team에서 자기 팀인 member를 알고 싶으면, 내 team_id를 가지고 있는 member들을 조회해 보면 된다. 그냥 join 하면 된다. 사실상 테이블의 연관관계는 방향이라는 개념 자체가 없다. 그냥 외래키 있으면 양쪽 둘 다 알 수 있다. 근데 객체가 문제다. 저렇게 객체지향적으로 바꾸게 되면, 과거처럼 객체도 테이블 설계적으로 세팅했다면 그냥 외래키로 소통하면 되었을 테지만.. 코드 @Entity public class Member { public Member..

저번 예제에서 Entity를 테이블 중심으로 설계를 했더니, 객체 입장에서 실제 참조를 가지지 않게 되었다. 어떻게 객체지향 적으로 설계를 할 수 있을까? 어떻게 실제 Order가 Member 객체를 참조하도록 설계할 수 있을까? 이렇게 관계형 DB와 객체 사이의 패러다임 불일치를 어떻게 해결할 수 있을까? 객체 : 주소, 참조를 통해 연관관계 설정 테이블 : 외래키를 통해 연관관계 설정 결국, 객체의 참조 부분과 테이블의 외래키 부분을 매핑 시켜야 한다. 이런 상태니, 음 근데 객체는 Member를 직접 가지고 있는 형태이고, 그러니까, DB의 저런 관계를 가져와서 객체로 만들어야 하는 것 인데, 일단 솔직히 insert는 쉬워보이고.. 쿼리를 그냥 Order 쿼리 날릴 때 Order Table에 미리..

요구사항 회원은 상품 주문 가능 주문 시 여러 종류 상품 선택 가능. 프론트엔드 체크하고 개수 입력 후 주문버튼 누르면 post 방식으로 전송 백엔드는 이런 느낌이려나..? 1 : N, N : N 이런 관계를 중요시 보는 듯. 한 회원은 여러번 주문 가능 (1 : N) 한 주문에 여러 상품 선택 가능 (1 : N) 한 상품은 여러 번 주문될 수 있음(N : 1) 테이블 설계 Member는 그냥 member고, orders는 주문이 있다는 어떤 식별자 같은 거 겠고, 주문의 상태 등도 나타낼 수 있는. 여러 order_item이 하나의 orders를 가리킬 수 있고, order_item과 item이 1:1 관계가 아닌 게 조금 의아했다. 그냥 order_item에서 count로 숫자로 나타내면 되는 거 아..

우리가 테이블에서 id에 넣는 그 키 그 테이블의 primary key 같은 것 들과 @Entity에서 어떻게 매핑을 할 지 id를 직접 넣어주고 싶다, @Id만. DB가 자동으로 Generate 해주는 것을 쓰고 싶다, @GeneratedValue를 추가해 줌. @Id @GeneratedValue(strategy = GenerationType.AUTO) private Long id; 전략 = 옵션 이렇게 넣는다. default가 AUTO이다. AUTO는 DB마다 좀 다르다. 아마 하이버네이트가 기본으로 설정한? 그런 건가 보다. 방언마다 다르다. 확인 해 보고 써야 함. 여튼 저게 기본값이고, 실상은 3개이다. IDENTITY SEQUENCE TABLE AUTO는 저 셋중 하나를 쓰는거다. IDENTI..

테이블 @Entity 매핑은 그냥 뭐 이름정도 맞춰준다거나 별거 없는데, 필드랑 컬럼은 좀 타입이라던지 몇개 있음. 요구사항 1. 일반회원과 관리자로 구분 2. 회원가입일과 수정일이 있어야 함. 3. 회원을 설명할 수 있는 필드가 있어야 하며, 이 필드는 길이제한이 없다. ?? 3번은 좀 위험한거 아닌가.. 여튼 그러면 id, username, 생성일, 수정일, 설명, 역할 요 6개쯤? @Entity public class Member { @Id private Long id; @Column(name="name") private String username; private Integer age; @Enumerated(EnumType.STRING) private RoleType roleType; ..