테이블에서 최종 사용자에게 값을 표시하는 드롭 다운 목록이 있습니다. 이 값을 알파벳순으로 정렬하고 싶습니다.
적절한 MVC 설계에 따르면 정렬 논리를 모델, 뷰 또는 컨트롤러 중 어떤 레이어에 배치해야합니까?
편집 : LarsH의 질문에 “원하는 정렬 순서를 결정하는 코드 또는 정렬을 수행하는 코드를 의미합니까?”
답변
(참고 :이 인용문과 인용은 @dasblinkenlight의 답변 에서 가져온 것이지만, 우리는 그 해석에 동의하지 않습니다. 그의 게시물을 읽고 자신의 마음을 구성하십시오).
MVC 설명 에 따르면 ,
컨트롤러는 모델의보기 표시를 변경하기 위해 명령을 관련보기로 보낼 수 있습니다 (예 : 문서를 스크롤하여). 모델 상태를 업데이트하는 명령을 모델에 보낼 수 있습니다 (예 : 문서 편집).
정렬 논리 (예 : 정렬 비교기 / 정렬 알고리즘)는 비즈니스 규칙 및 상태 데이터를 포함하므로 모델에 속합니다. 모델 데이터가 정렬되는 방식을 변경하는 것은 “모델의 뷰 표시 표현 변경”범주에 속하기 때문에 컨트롤러는 model.changeSortedState () 메소드를 호출하여 “정렬 수행”을 담당합니다.
답변
정렬 순서는 누가 제어합니까?
( Wikipedia에서 )
1) 데이터 자체의 자연스러운 순서 :
순서는 모델의 일부이므로 거기로 가야합니다. “모든 데이터”의 원시 풀은 정렬 된 순서로 데이터를 리턴하며 정렬 순서를 선택할 인터페이스가 없습니다.
2) 사용자는 데이터를 보는 방법을 제어해야합니다.
뷰는 컨트롤러와 상호 작용하는 인터페이스 (예 : 오름차순 / 내림차순 화살표)를 제공하며 모델은 데이터에서 요청 된 정렬을 수행하기에 충분히 데이터를 이해합니다. 그러나 (1)과 달리 원시 데이터 풀을 정렬 할 필요는 없습니다.
두 경우 모두
뷰는 어떤 정렬 방향이 선택되었는지 표시하는 기능 외에 다른 정렬이 있음을 이해하지 못합니다. 거기에 논리를 넣지 마십시오.
작은 경고
정렬 기능 은 하나의 상황에서보기에서 순전히 진행될 수 있습니다 (내가 생각할 수는 있지만 더있을 수도 있습니다).
모든 데이터가 이미 뷰에 있고 정렬을 수행하기 위해 도메인 지식을 사용할 필요가없는 “멍청한”정렬입니다. 예를 들어 매우 간단한 문자열 또는 숫자 비교. 예를 들어, 결과가 여러 페이지로 나눠 질 수있는 웹 페이지의 검색 결과에서는 불가능합니다.
답변
MVC 설명 에 따르면 ,
컨트롤러는 모델의보기 표시를 변경하기 위해 명령을 관련보기로 보낼 수 있습니다 (예 : 문서를 스크롤하여). 모델 상태를 업데이트하는 명령을 모델에 보낼 수 있습니다 (예 : 문서 편집).
이에 따르면, 정렬 논리는 컨트롤러에 속합니다. 모델 데이터가 정렬되는 방식을 변경하는 것은 “모델의 뷰 표시 표현 변경”범주에 속하기 때문입니다.
편집 : 주석에서 언급 된 여러 오해를 명확히하기 위해 “정렬 논리”는 정렬을 수행하는 코드 가 아닙니다 . 정렬 을 정의 하는 코드입니다 . 정렬 논리는 개별 항목을 서로 비교하여 순서를 설정하거나 (예 :의 인스턴스를 통해 IComparator<T>) 외부 시스템에 의해 (예 :의 인스턴스를 통해) 주문에 사용되는 객체를 구성하는 논리를 포함 IOrderedQueryable<T>합니다. 이 로직은 애플리케이션의 “비즈니스”측면과 관련된 지식이 필요하기 때문에 컨트롤러에 속합니다. 정렬을 수행하는 것으로는 충분하지만 실제로 수행 하는 코드와는 별개입니다.그것. 정렬 된 코드는보기, 모델 또는 모델을 뒷받침하는 지속성 계층 (예 : SQL 데이터베이스)에있을 수 있습니다.
답변
위의 어느 것도 아닙니다. 정렬은 비즈니스 로직이며 비즈니스 로직은이 세 가지 중 하나에 속하지 않습니다. 응용 프로그램의 모든 코드가 모델, 뷰 또는 컨트롤러가되는 것은 아닙니다.
MVC 앱에서 일반적으로하는 일은 모든 비즈니스 로직을 수행하는 서비스 계층이 있다는 것입니다. 서비스 계층의 메소드에는 매개 변수가 이름이 지정된 깨끗하고 간단한 API가 있어야합니다. 그런 다음 컨트롤러에서 해당 메소드를 호출하여 모델의 데이터를 조작 할 수 있습니다.
그런 의미에서 정렬은 “컨트롤러에서”이지만 정렬을 수행하는 코드 자체는 컨트롤러에서 구현되어서는 안되며 여기서 만 호출해야합니다.
답변
분명히 컨트롤러가 아님 : 메시지를보고 모델로 보내지 만 가능한 한 적은 작업을 수행해야합니다. 사용자가 정렬을 변경할 수있는 경우 해당 요청은 모델 또는 이에 대한보기를 알려 컨트롤러에 의해 처리됩니다.
순수한 View 일 경우 View 일 수 있습니다. 응용 프로그램이 정렬없이 잘 작동하면 정렬은 표현의 일부일 뿐이며보기로 이동해야합니다.
순서가 도메인의 고유 부분 인 경우 모델로 이동해야합니다.
답변
- 뷰는 프리젠 테이션 로직을 포함해야하는 MVC의 일부입니다.
- 모델 계층은 비즈니스 로직이 포함 된 곳입니다.
- 컨트롤러는 사용자 입력에 따라 두 상태 만 변경합니다.
선택은 도메인 비즈니스 로직 또는 프리젠 테이션 로직의 일부라고 생각합니까?
적절한 MVC Model2 또는 클래식 MVC 패턴을 구현하는 경우 모델 계층에서 제공 한 데이터의 순서는 모델 계층에 대한 뷰 요청에 의해 트리거되어야한다고 말합니다. 보기는 주문 된 데이터를 요청하고 모델 계층에서 제공합니다.
그러나 표준 MVC와 약간 다른 MVC 패턴의 ASP.NET MVC 해석을 사용하고 있기 때문에 ViewModel 인스턴스는 모델 계층에서 순서 정보를 요청해야합니다 (어떤 이유로 ASP.NET 프레임 워크는 템플릿을 호출해야한다고 생각합니다) “조회수”와 “조회수”는 “조회수”라고해야합니다.
답변
나는 보통 다른 답변에 따라 패턴과 일치하도록 컨트롤러에서 수행합니다. 추론에 대해서는 아래를 참조하십시오.
나는 이것을 숙고하고 답변과 관련 자료를 읽고 실용적으로 말하면 예를 들어 귀하의 응용 프로그램에 달려 있다고 말할 것입니다.
중형 / 대형 응용 프로그램이거나 여러 UI가 연결되어 있습니까 (예 : Windows 앱, 웹 인터페이스 및 전화 인터페이스).
- 이 경우 서비스 계층을 구성하여 비즈니스 오브젝트에 넣은 다음 컨트롤러에서 적절한 메소드를 호출합니다.
잘 정의 된 단일 UI 웹 사이트이고 EF Code First와 같은 것을 사용하고 있고 서비스 계층을 만들려는 의도가 없거나없는 경우 간단한 확장 방법을 사용하여이를 달성 할 계획입니다.
- 이 경우 아마도 컨트롤러를 시간 / 예산과 관련하여 실용적으로 가장 적합하게 넣었을 것입니다.
위의 BUT와 동일한 경우 즉시 사용 가능한 확장 방법으로 구현할 수 없습니다.
- 컨트롤러보다 여기에 더 적합하기 때문에 Model 클래스에 실제로 표시하도록 선택할 수 있습니다 (단일 유형에 맞는 경우). 정렬을 둘 이상의 클래스에 적용 할 수 있다면 확장 메서드에서 구현 한 다음 컨트롤러에서 호출합니다.
요약하면 :
교의 답변 : 서비스 계층
실용 답변 : 일반적으로 컨트롤러
