뷰 모델을 생성하기 위해 팩토리 클래스가 필요합니까?

필자의 동료는 ASP.NET MVC 솔루션에서 뷰 모델 객체를 생성하기 위해 팩토리 클래스를 사용할 것을 제안했습니다. 아이디어는 뷰 모델이 앱에 구축되는 방식의 설계 및 유지 관리에 도움이 될 수 있다는 것입니다.

다른 사람이 이것에 대한 경험이 있는지 알고 싶었습니다. 나는 약간의 연구를 해왔고이 연습에서 거의 발견하지 못했다.

현재 컨트롤러 수준에서 viewmodel 객체를 생성합니다.

public ActionResult Index()
{
    return this.View(this.BuildIndexViewModel());
}

따라서 this.BuildIndexViewModel ()은 viewmodel 클래스를 작성해야합니다 (분명 :). 그러나 우리는 다음과 같은 가능성을 조사하고 있습니다.

public ActionResult Index()
{
    return this.View(ViewModelFactory.CreateIndexViewModel());
}

이것은 흥미로운 아이디어이지만 100 % 확신하지는 않습니다. 나는 이것에 대한 다른 사람들의 의견에 관심이 있었다.

design asp.net-mvc

— 제이슨 에반스
소스

나는 정직한 이익을보기 위해 고군분투합니다. 팩토리를 사용하여 객체의 구성을 숨길 수 있지만이 경우 왜 하시겠습니까?

— CodeART

BuildIndexViewModel 메소드는 이미 컨트롤러에 대한 팩토리 메소드입니다. 다른 팩토리 클래스로 추출하는 유일한 이유는 다른 컨트롤러에서 재사용하는 것입니다.

— MattDavey

둘 다 이것에 대해 나와 같은 생각을 공유하므로 혼자가 아니라 기쁘다 :) @MattDavey 나는 솔직히 뷰 모델이 하나 이상의 컨트롤러와 함께 사용될 것이라는 점을 의심 할 수있다. 중복 아이디어. 나는 주제가 직장에서 다시 올 때 이것을 공유 할 것입니다.

— Jason Evans

개인적으로 나는 뷰 모델 유형을 스스로 구성하는 과정의 전문가로 선호합니다. 건설 당신이 할 수있는 경우에 다른 응용 분야 (예 : 저장소)에 대한 지식, 필요한 경우 전문 지식을 다른 곳에 배치해야하는 유일한 시간은 원하는 :) 바보 뷰 모델을 유지하기 위해 중개인

— MattDavey

@MattDavey :이 두 의견을 내가 찬성 할 수있는 답변으로 감쌀 수 있습니까?

— pdr

이 경우 따라야 할 최상의 지침은 GRASP 원칙이라고합니다. 특히 객체 생성을 할당하는 4 가지 기준을 살펴보십시오.

일반적으로, 클래스 B는 다음 중 하나 이상이 바람직 할 경우 클래스 A의 인스턴스를 작성해야합니다.

B의 인스턴스는 A의 인스턴스를 포함하거나 종합적으로 집계합니다.
A의 B 레코드 인스턴스
B의 인스턴스는 A의 인스턴스를 밀접하게 사용합니다.
B의 인스턴스는 A의 인스턴스에 대한 초기화 정보를 가지며 작성시 전달합니다.

컨트롤러 클래스 (B)는 해당 목록의 3 번과 4 번 항목 (뷰 모델이 POST 된 경우 2 번)과 일치하므로 이미 뷰 모델 (A) 구성 동작이 작동하기에 매우 합리적인 장소입니다. 내가 알다시피, 그 구성 행동을 전문가 클래스로 추출 해야하는 이유는 두 가지뿐입니다.

DRY- 둘 이상의 컨트롤러가 뷰 모델 구성 동작을 공유해야하는 경우 별도의 구성 요소로 캡슐화하면 코드 재사용이 용이하고 복제를 피할 수 있습니다.
구성 동작이 리포지토리, 유효성 검사기 등의 다른 시스템 구성 요소에 종속되어 있고 컨트롤러에이 커플 링을 도입하지 않으려는 경우 (GRASP 용어로 순수 제작).

GRASP의 4 가지 객체 생성 기준을 되돌아 보면, 그 목록에서 추가적인 진드기가 나올 경우에만 별도의 팩토리로 동작을 추출합니다. 그렇지 않으면 그렇게 할 가치가 없습니다.

희망이 도움이됩니다!

— 맷 다비
소스