솔직히,, MVC나 MVP나 MVVM이나 머가 그렇게 다른지 잘 이해가 안가긴합니다.. 모델과 뷰를 분리하고 이를 컨트롤하는 영역을 어떻게 처리하면 좋을까 하는데서 조금씩 차이가 있어서 구분하려는게 목적인 걸까요. 뷰모델이라 한다해도 처리해야할 복잡성이 올라가면 결국 복잡해지는 건 똑같아 보입니다.. 그럼에도 불구하고 UIKit을 사용할 때 NVVM을 쓸라고 하는건 테스트가 용이하다는 이유랑, 그냥 옵저버 패턴 쓰고 싶어서인 것 같습니다. Combine이 나온 것도 뭔가 너네가 옵저버 방식 좋아하는 것 같으니까 만들었어 같은 느낌인 것 같고,, SwiftUI를 공부하면서 보니까 자연스럽게 Combine 쓰게되고 쓰다보니 자연스레 아래처럼 구조가 분리되는 것 같은데 이게 NVVM이 맞는 걸까요? 뷰(들어오는 데이터 대로 그려지는 뷰 구조체 모음) 모델(타입 or 인터페이스 모음) 로직(뷰의 로직 처리 함수모음) 스토어(상태 데이터모음)
안녕하세요. 강의 정말 잘 들었습니다. 많은 도움이 되고 있습니다. 다름이 아니고, 각 도메인모델을 도출하고 난 후, 경우에 따라 여러 모델을 일관성 있게 업데이트해야하는 경우 유스케이스(서비스)를 이용하게 되는데요. 유스케이스의 디자인은 어느 시점에 어떻게 해야하는지 궁금합니다. 강의내용에서는 모델(entity)만을 도출하고 난 후, 패턴을 언급하며 마무리하고 있어서, 실질적으로 구현을 위한 유스케이스 디자인 단계가 빠져 있는거 같아서요. 감사합니다!
강사님! 직렬화 라이브러리를 Moshi, kotlin serialization 두개를 사용하시던데 이유가 있으신가요? 찾아보니까 코틀린의 serialization 만 이용해도 되지 않을까해서요 retrofit 에서도 제이크와튼이 만든 컨버터 라이브러리도 있더라구요? https://github.com/JakeWharton/retrofit2-kotlinx-serialization-converter#download 그런데 0.8 버전이긴하네요;;; 혹시 어떤 이유가 있으셔서 room 에는 serialization, retrofit 에는 moshi 를 사용하신걸까요?! 그리고 매번 답변해주셔서 정말 감사합니다 (__)
안녕하세요! 좋은 강의 제공해주셔서 감사합니다. 다름이 아니라, 수업에서 JWT 토큰 유효성 로직을 api gateway service에 구현했는데, user-service가 아닌 gateway service에 구현한 이유가 있을까요? api gateway에 토큰 유효성 로직을 구현하게 되면, 만료된 토큰으로 api gateway를 거치지 않고 바로 user-service에 요청하는 경우, 토큰 유효성 검사를 하지 않아서 문제가 발생할 수 있지 않나요?
EditText 는 saveState 가 활성화되어있어서 id 만 지정하면 시스템언어변경하거나해도 잘 불러오더라구요 그래서 강사님처럼 kill 명어로도 강제 종료를 시켜봤는데 그래도 잘 복원이 되더라구요 강의에서 kill 로 종료하면 복구가 안되기 때문에 직접 뷰모델에 SaveStateHandle 을 이용하신다고 했는데 그럼 실제 개발할때는 EditText 뷰인경우 SaveStateHandle 을 사용하지 않아도 될까요?
안녕하세요. 강의를 수강하던 중 이해하기 힘든 현상을 발견되어 이렇게 질문드립니다. Jwt는 SigningKey로 복호화가 가능하다면, 유효한 토큰이다.(유효한 토큰이다란 기준이 여러 개 있습니다만) 라고 알고 있는데요. 아래와 같은 현상을 발견하게되서 질문하게 되었습니다. (현재 Gateway server - token.secret = A) (현재 User service - token.secret = A) 1.User-service 회원생성 2.User-service 로그인 (응답에서 jwt토큰 복사) 로그인 시 User-service의 token.secret을 SigningKey로 jwt 토큰 발급 3.Gateway의 AuthorizationHeaderFilter를 통과하는 user-service/actuator/health 호출 (response, 200) 여기까지는 정상입니다만 4.ecommerce.yml의 token.secret 변경 및 커밋 5.Gateway의 /refresh 호출 액츄에이터에 의한 token.secret 변경 (현재 Gateway server - token.secret = B) (현재 User service - token.secret = A) (현재 JWT 토큰의 SigningKey = A) 6.Gateway의 AuthorizationHeaderFilter를 통과하는 user-service/actuator/health 호출 ( response, 200 ) 여기가 질문 포인트입니다. AuthorizationHeaderFilter의 isJwtValid의 코드를 보면 subject = Jwts.parser().setSigningKey(env.getProperty("token.secret")) .parseClaimsJws(jwt).getBody() .getSubject(); 이런 구문이 있습니다. Jwt 생성 당시의 Siginingkey랑 다른 signingkey로 복호화하면 오류가 나면서 인가에 실패하는 것을 기대했습니다. 하지만 왜 정상적으로 200을 반환하는지 이해가 잘 되지 않습니다. (Gateway의 token.secret은 B로 변경됨을 로그로 확인했습니다. )
안녕하세요. 먼저 좋은 수업을 강의 해주셔서 감사합니다! 다름이 아니라 제가 해당 수업 진행 중 오류가 있어서 문의드립니다! mysql 콘솔에서는 오류가 발생 하지 않았으나, H2 Console 에서 테이블을 조회시 SELECT * FROM ORDERS; (conn=42) Table 'mydb.ORDERS' doesn't exist 42S02/1146 이러한 에러가 발생하는데 원인이 무엇일까요?? order-service 에서 조회시에는 문제가 없습니다..
책검색 구현 내용 설명해주실때 EditText 는 액티비티가 재생성되어도 값이 남아있던데 조금만 더 자세하게 왜 그런지 키워드만이라도 좀 알려주실까요? EditText 에서 어떤부분을 찾아봐야 알 수 있는지 모르겠네요.. 아 질문등록하고 좀 더 찾아봤는데 saveEnabled 속성으로 알아보면되겠네요 View는 기본적으로 saveEnabled="true"가 기본값 입니다.
마이크로 서비스 사용간 (RestTemplate 혹은 Feign) 에서 Eureka 의 서비스 명으로 USER-SERVICE 같은 마이크로 서비스명을 통하여 직접 호출하면 결론적으로는 GATEWAY-SERVICE 를 통하여 사용했을때의 장점을 잃어버리는 것 같은데, 섹션 10 에서는 게이트웨이를 통하지 않고 직접 서비스를 호출하는 이유가 있을까요?
대여 모델링 강의에서 RentalItem<VO>에서 overdued, overdueStartDate라는 맴버 변수가 있는데요. 혹시 이걸 반납 예정일을 나타내는 dueDate로 바꾸면 어떨까요? 이러면 ReturnItem<VO>에 RentalItem<VO>를 추가할 때 바로 추가할 수 있을거 같고, 반납 예정일을 연장한다고 했을 때 유연하게 대응할 수 있을것 같습니다. 좋은 강의 감사합니다. ^^
MSA에서 다른 어플리케이션의 데이터를 가져오는 방법으로 RestTemplate, FeignClient를 사용하는 방법을 알려주셨는데요. 데이터를 가져오는 것은 보통 rest 통신을 사용하여 가져오나요? 실무에서 카프카나 다른 라이브러리를 사용해서 가져오는지, 아니면 설명해주신 것 처럼 rest 통신을 통해 가져오는지 궁금합니다~
안녕하세요 선생님, 자세한 도메인 기술은 어렵다고 생각해서 간략하게 상황을 가정하겠습니다. 기존에 있던 애그리거트는 한 뭉탱이로 돌아다녔는데 기획이 변경되어 스토밍으로 추출했던 기존 애그리거트 루트와 VO 객체가 서로 생명주기가 다른 상황이 되었습니다. 루트가 VO를 리스트로 가지고 있으며 루트가 생성되고 특정 이벤트 후에 VO가 생성되어 루트에 추가되고 일정시간이 지나면 VO를 업데이트 해야 하는 상황입니다. VO가 불변객체라 리스트에서 새로운 객체로 갈아치우 것도 아닌 거 같아서,, 현재 억지로 갈아치우게끔 만들어 놓긴 했습니다,, 또, 아무리봐도 서로 생명주기가 달라 VO를 다른 애그리거트로 전환하려고 하는데 제가 애그리거트들을 수정하는데 있어 근거가 부족하거나, 놓치는 부분이 있을까요?
즐겨찾기 아이템 삭제시 undo를 할 때 아이템이 원래있었던 위치로 오게 하려면 autoGenerate의 id항목을 추가해 primaryKey로 지정하면 된다고 하셨는데요 Book 이 API로 책정보를 가져오는 용도로도 사용해서 Search할 때 documents에 id가 없다는 에러가 발생합니다 이를 해결하기 위해선 DB에 사용할 Entity를 따로 생성해 id항목을 추가해주어야 하나요?
안녕하세요. 강의 잘 듣고 있습니다. 강의를 듣던 중 아래 몇 가지 이해가 부족한 부분과 조언이 필요한 부분이 있어 이렇게 질문 남깁니다. 제가 이해하기로, Spring Cloud Config는 애플리케이션의 환경정보(이하 env)를 외부로부터 받아오기 위한 의존성이며, Spring Actuator의 /refresh는 단지 env를 업데이트 하기 위해 사용하는것 뿐이다. 둘 사이의 종속적인 부분은 없어보인다. 식으로 이해를 했습니다. 제가 생각한 것이 맞는지 궁금합니다. 혹은 참고해서 공부할 수 있는 키워드가 있다면 참고하여 학습하도록 하겠습니다. @Component 어노테이션으로 Spring Bean이 등록이 될 때, @Value 어노테이션을 통해 환경정보를 주입받을 수 있는 것을 알고 있습니다. 직접 확인을 해보니 /refresh는 Environment의 값은 바꾸지만, @Value를 통해 주입된 필드값은 수정되지 않음을 볼 수 있었습니다. Spring Cloud Config를 도입한다고 하면 @Value를 통해 주입받던 모든 곳을 Environment를 통해 가져오는 것으로 수정을 해야하는지 혹은 다른 해결방안이 있는지 궁금합니다. 감사합니다.
