묻고 답해요
141만명의 커뮤니티!! 함께 토론해봐요.
인프런 TOP Writers
-
미해결
스프링에서 @CreatedBy 와 AuditorAware 의 활용에 질문 드립니다!
@CreatedBy을 이용하면, 디비에 데이터가 입력될 때마다 작성자의 정보를 자동으로 기입할 수 있어서 많은 분들이 이용하시고 있습니다. 그리고 해당 @CreatedBy 값에 들어 갈 값은 AuditorAware을 통해 만들 수가 있는데요.<Q. 질문>그러나 만일.. 아래와 같이 생성시 점에서 ID 값과 Name 을 입력해 주어야한 다면... AuditorAware를 어떻게 이용해서 아래의 내용을 기입할 수 있는지 알고계신 분 있으실까요?(@CreatedBy 가 특정 AuditorAware 파일을 지정할 수 있으면 될 것 같은데... 방법을 못찾았습니다 ㅠ)@CreatedByprivate Long creatorId;@CreatedByprivate Stirng creatorName;
-
미해결Java TPC 실전프로젝트 (Java API 활용)
채팅관련 질문입니다
안녕하세요 !! 자바 TPC부터 스프1탄, 2탄 등 좋은 강의 잘 보고 있는 학생입니다 !항상 좋은 가르침 주셔서 감사드려요 ㅎㅎ다름이 아니라 해당 자바 기술을 통해 Spring FrameWork 환경에서 채팅 기능을 구현하고자 하는데요..아직 초보라서 어떤 객체에 어떤 내용을 담아야 하는지,화면에 구현할 때 실시간으로 대화가 진행되게 하려면 감이 안오는 상황입니다.. 명령 프롬프트에서가 아닌 웹 뷰 페이지 내에서도 채팅 기능 구현이 가능할까요 ,,?가능하다면 어떻게 할 수 있을까요 ..? ㅠㅠ주제에 조금 벗어난 질문일지 모르지만 웹 페이지에서도 구현이 하고 싶어 여쭈었습니다..!답변 남겨주시면 정말 감사드리겠습니다 ㅠㅠ
-
미해결스프링 핵심 원리 - 기본편
스프링에서 디자인패턴 적용
안녕하세요? 영한님 강의를 너무나도 잘 듣고, 실무에 적극 활요하며 성장 중인 주니어 개발자입니다. 먼저, 항상 좋은 강의 제공해주셔서 감사합니다. (벌써 3번째 듣는중인 강의입니다!) 다름이 아니라, 최근에 영한님께서 추천해주신 객체지향의 사실과 오해라는 책과, 오브젝트라는 책을 정독했어요. SOLID원칙에 조금 더 자세하고 정확하게 대해서 알게 되었고, 객체를 설계하는 법, 책임주도 설계 등 다양한 객체지향 원칙들을 배우고 학습하였는데 이를 실무에 어떻게 적용해나가야 할지 궁금합니다. Q1. 강의 중 [조회한 빈이 모두 필요할 때, List, Map] 에 나온 내용과 같이, 하위의 구체 타입 클래스들을 모두 Spring Bean으로 등록시키고 애플리케이션 컨텍스트가 실행되는 시점에 의존관계를 맺어주고, 필요한 상황에 따라서 필요한 Bean을 찾아서 알고리즘을 수행하면 되는 걸까요? 강의에서 말씀해주셨던 Strategy 패턴과 같이 다른 디자인 패턴들도 비슷한 방식으로 적용해나가면 될지?에 대한 궁금증이었습니다. Q2. 그렇게 된다면, 특정한 인터페이스를 설계하고 그 인터페이스를 구현하는 객체들은 모두 Spring Bean으로 등록되어야 할 것 같은데 방식이 맞을까요? Q3. 그리고 외부에서 어딘가 협력하는 객체의 구체 타입에 대한 정보를 알고 있고 전달해주어야 하는데, 예를 들어 강의에 나온 것처럼 파라미터에 구체 타입에 대한 문자를 받고 진행한다면 컨트롤러 레이어에서 해당 문자를 전달 해주면 컨트롤러 계층은 호출하는 서비스 계층이 어떤 클래스들과 협력하는지에 대한 정보를 알아야 하므로, 이는 캡슐화가 위반되는 것이 아닌가 싶기도 합니다. 왜 이렇게 생각했는지 말씀드리자면 1) 컨트롤러 계층에서는 Serivce 클래스가 누구와 의존하고 있는지 알아야 합니다. 2) Service 클래스가 의존하는 대상이 추상화여도 그 추상화의 구체 인스턴스의 종류들에 대해서 알고 있어야 합니다. (그래야 원하는 알고리즘을 수행 가능) 3) 캡슐화는 단순히 객체의 내부 상태를 숨기는 것 이상의 의미를 가진다고 생각합니다. 만약 구체 인스턴스의 종류가 삭제된다면 분명 컨트롤러 레이어에서도 변경에 대한 여파가 있을 것 같다는 생각이었습니다. 4) 이를 무시하고도 실무에서는 보통 이런식으로 구현을 많이 하는 편일까요? Q4. 제가 너무 Controller - Service - Repository의 일반적인 MVC 레이어에서 벗어나지 못하는 것이라고 생각이 들기도 했습니다. 일반적으로 대규모 서비스를 운영하는 회사에서도 한 마이크로 서비스 내에서 Controller-Service-Repository 구조를 가져가는지 궁금합니다. 네이밍을 조금 다르게 한다던지, 패키지 구조가 조금 다르다던지.. 그런 내용들이 있을까요? (현재 프로젝트 구조는 멀티 모듈화 시켜서 협력 패턴이 최대한 다른 컨텍스트에서도 재사용 될 수 있도록 프레임워크/라이브러리화 시키면서 설계해보려고 노력 중입니다. 그래도 애플리케이션 모듈은 C-S-R 구조를 벗어나기가 힘든 것 같아요) 작은 스타트업에서 주니어 혼자 끙끙 앓고 있어 답답한 마음에 여기에라도 질문을 올려봅니다. 너무 막연한 질문이라, 답변 주시기 어려울 것 같은 부분이 있다면 답변 안 주셔도 괜찮아요. 강의 제공 받는 것만으로도 저에게는 정말 큰 도움이 돼요 (사실 저도 어떻게 질문할지 막막해서 제가 봐도 어렵네요..) 항상 도움 주셔서 감사합니다 영한님 :)