JavaScript를 사용한 클린 아키텍처 방법(Repository 편)

결말과 결말은 같습니까?

  • 지속적인 데이터를 얻기 위한 인터페이스
  • 의존관계가 역전되는 상황을 잘 몰라서(연기)
  • 먼저 다음 Labor Repository부터 시작합니다.
  • window.addEventListener("DOMContentLoaded", function(evt){
    
      const repository   = new LaborRepository(COMPANY);
      const presenter    = new Presenter();
      const filterUC     = new filterUsecase(repository, presenter);
      const viewController = new Controller(filterUC);
    
      viewController.onload(evt);
    })
    

    Labor Repository: 버전 0

  • 수수하다
  • LINQ 메서드가 있는 Table 객체 컬렉션
  • 방법의 반환값은 기본Table의 사상
  • Table에서 Aray까지의 길이
  •    //こんなのとか
    class FilterUsecase {
       //こんなのとか
      filterByDepartment(table){//Usecase中ではpresenterが受け取れる配列データ構造に変換
        //この場合はTable -> Arrayへ; "所属"の列だけを抜き出して配列へ
        return table.select("所属").uniq()
          .left_join(this.repository.from("所属部門"), (a, b)=>{return a["所属"]==b["部門名"]}.orderby("表示順")
          .select("所属").toArray()   
      }
      //こんなのとか
      filterByMember(table){
          return table.select("氏名").uniq()
             .left_join(this.repository.from("従業員"),(a, b)=>{a["氏名"]==b["名前"]}).orderby("表示順").toArray()
      }
    }
    

    Domain 모델로서 최종 결과에 근접한 결과를 얻는 것은 적절하다

  • 사전 조건부 작업 실적 검색
  • const 업무 실적표 =this.repository.q("작업 실적",this.cond)
  • const departments = this.filterByDepartment(근무 실적표)
  • 표 구조와 속성 명칭은 회사 고유의
  • Repository에 COMPANY 정보 필요
  • Usecase의 역할은 Domain Model의 데이터 형식 변환입니다.

  • const departments = this.repository.departments(this.cond)
  • 이렇게 간단하게 하는 게 좋아요
  • 그러나 Repository API
  • 로 증가

    Usecase는 "순서"를 기술하는 역할도 합니다.

  • 여기는 수준 높은 API
  • 가 있어야 한다.

    Labor Repository 수정 사항



    Domain Model에 대한 고찰


    이해하다.

  • Repository 측면에 데이터 변환이 있으므로 Usecase가 명확함
  • Entity->DomainModel
  • 다른 한편, Usecase로서의 데이터 변환은 반드시 보존해야 한다.
  • View에 필요한 데이터 구조를 준비할 수 없음
  • 뷰가 Repository
  • 를 알 수 있도록 하기 위해
  • Repository가 View를 모르게
  • 의문

  • 최선을 다해서 데이터를 넘겨드리겠습니다. 뷰 쪽도 잘 부탁드립니다.
  • 일반: 데이터 구조가 변경될 때마다 View 측도 변경됩니다
  • .
  • 어쩔 수 없는 일되다
  • 문제가 있는 경우 동적 페이지

  • 데이터 구조가 페이지 구조에 반영된 상황
  • 간단한 배열과 값 정도의 데이터 요소는 문제가 되지 않는다
  • 패브릭 데이터
  • 트리 또는
  • 신입사원의 나무 구조는 사람에 따라 다르다
  • Repository에서 얻은 데이터의 내부 구조를 몰라도 데이터 구조를 이해할 수 있다
  • 패브릭 이퀄라이저 등을 교환된 데이터에 정의할 수 있으면 View가 견고해집니다
  • .
  • 반환값도interface?

  • 저는 아마 그런 줄 몰랐어요.
  • 총결산

  • Repository가 인터페이스인 이유는 무엇입니까?
  • Usecase의 본래 역할이 명확해지다
  • 비즈니스 단계 기술
  • 다른 한편, Usecase로서의 데이터 변환은 반드시 보존해야 한다.
  • View에 필요한 데이터 구조를 준비할 수 없음
  • 뷰가 Repository
  • 를 알 수 있도록 하기 위해
  • Repository가 View를 모르게
  • Domaain 모델이 균형기를 가지고 있다면 View는 구할 수 있을 것 같다
  • 반환값도 인터페이스와 어떻게 된 일입니까?필요했어
  • 아직 몰라
  • DataStore 편에 이어


    모든 메시지

  • JavaScript를 사용한 클린 아키텍처 방법(전편)
  • JavaScript로 클린 스키마 만들기 (Usecase 편)
  • JavaScript에서 녹색 구조를 어떻게 만들어야 좋을까요(Presenter 편)
  • JavaScript로 클린 스키마 만들기 (initializer 편)
  • 자바스크립트에서 어떻게 청결 구조를 진행하는가(Repository 편)
  • JavaScript를 사용한 클린 아키텍처 방법(DataStore 편)
  • JavaScript를 사용한 클린 아키텍처 방법(Domain Model 편)
  • 좋은 웹페이지 즐겨찾기