정렬 로직을 모델, 뷰 또는 컨트롤러에 배치해야합니까? [닫은]

테이블에서 최종 사용자에게 값을 표시하는 드롭 다운 목록이 있습니다. 이 값을 알파벳순으로 정렬하고 싶습니다.

적절한 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 클래스에 실제로 표시하도록 선택할 수 있습니다 (단일 유형에 맞는 경우). 정렬을 둘 이상의 클래스에 적용 할 수 있다면 확장 메서드에서 구현 한 다음 컨트롤러에서 호출합니다.

요약하면 :

교의 답변 : 서비스 계층

실용 답변 : 일반적으로 컨트롤러

드롭 다운 목록에 유용 할 정도로 작은 테이블 데이터에서 데이터를 정렬하는 것이 좋습니다. 이미 쿼리를 통해 정렬 된 DB에서 가져와야합니다. 나에게 그것은 정렬이 적용되는 장소를 모델로 만든다.

손으로 정렬하기로 결정했다면 모델이나 컨트롤러를 선호하는 로직으로 사용하는 것에 대한 좋은 주장이 있다고 생각합니다. 제한은 특정 프레임 워크입니다. 모델에서만 데이터를 관리하는 것을 선호합니다. 컨트롤러를 사용하여 (자기) 가르쳐 왔던 것처럼 데이터 (모델) 및 프레젠테이션 (보기)을 결혼시킵니다.

정렬이 Business Logic이라는 아이디어에 원칙적으로 동의하지만, 정렬 방식을 원점으로 분류하면 "고객이 제품 페이지에 날짜별로 정렬 된 이미지가 표시되도록 할 것"과 같은 결과를 얻게됩니다. 데이터에 대한 정렬 순서는 일반적으로 임의적이지 않습니다. 정렬이없는 경우에도 누락에 의한 비즈니스 결정이므로 비어있는 목록은 여전히 ​​목록입니다.

그러나 ...이 답변은 ORM 기술의 진보를 고려하지 않는 것 같습니다 .Entity Framework와 관련하여 만 이야기 할 수 있습니다 (이것이 참 ORM인지 여부에 대한 논쟁은 피하십시오). 그것이 제가 사용하는 것이지만 다른 ORM도 비슷한 기능을 제공합니다.

MS MVC와 Entity Framework를 사용하여 Product 클래스에 대해 Strongly Typed 뷰를 만들고 Product와 Image 테이블 (예 : FK_Product_Image_ProductId)간에 외래 키 관계가 있으면 즉시 정렬 할 수 있습니다. 뷰에서 다음과 같은 것을 사용하여 디스플레이하는 동안 이미지 :

@foreach(Image i in Model.Image.OrderBy(e => e.DisplayOrder)){ //etc etc... }

비즈니스 로직의 80 %를 수행하는 데 사용하는 특정 Business Logic 계층에 대한 언급이 있었지만 기본 제공되는 것을 모방하는 정렬 기능을 Business Logic 계층에 쓰지 않습니다. Entity Framework에서.

나는이 질문에 대한 정답이 아니라고 생각합니다. 복잡한 비즈니스 로직을 가능한 한 추상화해야하지만 휠을 재발 명하는 비용은 발생하지 않아야합니다.

MVC 웹 사이트, WebForms 웹 사이트 및 모바일 애플리케이션이 있다고 가정하십시오.

이러한 프리젠 테이션 레이어간에 정렬을 일관되게하려면 프리젠 테이션 레이어 외부에서 정렬이라고합니다. 서비스는 좋은 후보가 될 것입니다.

그렇지 않으면 해당 논리를 뷰 모델에 저장합니다. 왜? 재사용이 가능하고 쉽게 테스트 할 수 있기 때문입니다.

나열된 세 가지 중에서 컨트롤러에 속한다고 말할 수 있습니다. 그래도 컨트롤러에 이런 종류의 논리를 배치하는 것을 좋아하지 않습니다. 나는 보통 컨트롤러가 통신하는 서비스 계층을 만들어 데이터 저장소와 통신하고 정렬 논리를 처리합니다. 작은 응용 프로그램의 경우 컨트롤러에 앉아 있으면 좋습니다.

이것은 asp.net을 염두에두고 묻는 질문이지만 누군가 Rails를 언급했기 때문에 그 맥락에서 문제를 고려하는 것이 흥미로울 것이라고 생각했습니다. Rails에서는 프레임 워크와 ActiveRecord / ActiveQuery API가이를 제공하기 때문에 컨트롤러 작업으로서 검색과 함께 정렬을 수행하는 것이 자연스럽고 일반적입니다. 반면에 정적 항목에 대한 일종의 사용자 지정 정렬 순서를 정의하고 컨트롤러에서 사용할 모델에 넣을 수 있으므로 모델이 수행하지 않아도 정렬 논리의 일부를 재생할 수 있습니다 직접 작업. 그것이 무엇이든간에, 정렬 논리를보기에 넣는 것은 일반적으로 싫은 것이라고 말할 수 있습니다.

나는 약간의 대답이 컨트롤러 또는 모델에 정렬하는 것에 절대적으로 반대하고 내 취향에 너무 관대하다고 생각하지만 사용 된 프레임 워크의 특성과 관련된 일반적인 규칙에 달려 있다고 가정합니다. 그것. 나는 또한 분리를하는 것이 더 중요하다는 Bill K의 의견에 동의합니다.