🔥 목차 🔥

1.Repository 패턴

🧐 그렇다면 꼬! 🧐

💡 서론

• Repository 패턴을 분석하기 전에 발생된 배경과 비즈니스 로직에 대해서 설명을 하는게 좋을듯 하다
• 흔히 비즈니스 라고하면 사업을 생각한다
  • 하지만 컴퓨터 공학에서의 비즈니스의 맥락은 조금 다르다
  • 비즈니스 라는 말은 소프트웨어가 풀고자 하는 현실 세상의 문제를 가르킨다고 한다
  • 즉 소프트웨어가 존재하는 이유, 그리고 목적이다
  • 비즈니스 로직은 위에서 얘기했던것 처럼 프로그램의 핵심 조직을 뜻한다
• 러프하게 정리한다면 어떻게 데이터가 생성되고 수정되는것 등을 정의한게 비즈니스 로직이라고 할 수있다

💡 Repository 패턴

• 서론을 보면 이런질문을 할 수있다

그래서 비즈니스 패턴이 Repository 패턴에 정확하게 어떤 영향을 주는데?

• 해당 내용을 설명하기 위해선 Repository 패턴이 정확히 뭘하는 녀석인지 알아야 설명이 가능하다
• 개념부터 설명하자면 데이터의 출처를 알 수 없게 하고 일관된 인터페이스로 데이터를 가져올 수 있도록 하는것을 Repository 패턴이라고 한다
• 해당 내용을 현 시점 Front End 개발자인 나를 중점으로 얘기해보겠다
  • Fornt End 개발자는 보여지는 View Model을 중점으로 신경쓰고 상호작용등을 개발하는 직종이다
  • 그걸 다르게 해석하면 Front End는 다른 데이터 들에 의존도가 크다는걸 알수있다
  • View Model을 개발할때의 기본 디자인 시안이 나와야 그거에 맞게 코드를 작성하고
  • API나 등등의 데이터가 들어와야 그 데이터를 가공하고 분석해서 View Model에 뿌려줄수가 있다
• 개발은 디자이너 , 백엔드 개발자 등등 많은 직종들이 동시에 시작한다
  • 하지만 Front End 개발자는 그들이 개발한 결과물을 가지고 개발을 시작해야하는데
  • 이는 보는사람도 느끼겠지만 비효율적이다
• 그리고 웹 개발을 하다보면 확장성을 고려해야 하는데 확장성 측면에서도 데이터가 없는 상태에서는 확장을 고려하는게 쉽지만은 않은부분이다
• 이러한 문제들을 고려해 보았을때 우리는 이런 생각을 좀 해볼수 있다

그럼 데이터가 있다는 가정하에 개발하면 되는거 아니야?

• 필자 본인은 정말 이말을 좋아한다
• 데이터가 없어서 개발을 못한다 라는말이 어찌보면 맞는말이다 하지만 데이터없다고 평생 개발을 못하는것도 아니지않는가..?
  • 그렇다면 우리가 임시의 데이터를 만들어보면 되는게 아닐까? 라는 생각을 좀 해보았다
  • 그 시작이 이 글을 작성하기 시작한 계기 이기도 하다
• 그 생각이 닿는 지점이 바로 Repository 패턴이다
  • View Model은 어떠한 데이터를 랜더링 할때 그 데이터가 API인지 혹은 Dummy Data인지 알아야 하는 이유가 없다
  • View Model의 입장에서는 코드를 확인해서 그 코드에 어떤 데이터가 들어왔고 그 데이터가 어떤 정보이든 간에 뿌려주기만 하면 된다
  • 들어온 정보가 API이든 임시데이터든 알빠가 아니라는 소리다
• 그럼 우리가 생각해야 할 부분은 데이터가 어떠한 형태로 들어올껀지에 대한 정보만 안다면 임시 데이터 객체나 파일을 만들어서 사용 할 수 있을것 같다
• 백앤드 개발자가 API를 어떤식으로 만들고 어떤 객체의 이름에는 어떤 정보가 들어있고 등등의 정보를 넘겨받는다면
• Fornt End 개발자는 그 정보를 확인해서 임시 데이터를 만들어서 개발을 시작 할 수 있다는것
  • 그렇게 되면 위에서 이야기 한대로 확장성 부분에서도 데이터를 교체해주기만 하면 되기때문에 확장성도 해결된다
  • 그리고 비즈니스 로직을 분리해서 코딩하는것도 가능해지기 때문에 위에서 얘기한 비즈니스 패턴이 Repository 패턴에 주는 영향에 대해서도 답을 유추 해볼수 있다.