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

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

---

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

적절한 MVC 설계에 따르면 정렬 논리를 모델, 뷰 또는 컨트롤러 중 어떤 레이어에 배치해야합니까?

편집 : LarsH의 질문에 "원하는 정렬 순서를 결정하는 코드를 의미합니까? 또는 정렬을 수행하는 코드를 의미합니까?"라는 응답으로 원래 정렬 순서를 결정하는 코드를 언급했습니다.

---

(참고 :이 인용문과 인용은 @dasblinkenlight의 답변 에서 가져온 것이지만, 우리는 그 해석에 동의하지 않습니다. 그의 게시물을 읽고 자신의 마음을 구성하십시오).

MVC 설명 에 따르면 ,

컨트롤러는 모델의보기 표시를 변경하기 위해 명령을 연관된보기로 보낼 수 있습니다 (예 : 문서를 스크롤하여). 모델 상태를 업데이트하는 명령을 모델에 보낼 수 있습니다 (예 : 문서 편집).

정렬 논리 (예 : 정렬 비교기 / 정렬 알고리즘)는 비즈니스 규칙 및 상태 데이터를 포함하므로 모델에 속합니다. 모델 데이터가 정렬되는 방식을 변경하면 "모델의 뷰 표시 표현 변경"범주에 속하기 때문에 컨트롤러는 model.changeSortedState () 메소드를 호출하여 "정렬 수행"을 담당합니다.

---

정렬 순서는 누가 제어합니까?

( Wikipedia에서 )

1) 데이터 자체의 자연스러운 순서 :

순서는 모델의 일부이므로 거기로 가야합니다. "모든 데이터"의 원시 풀은 정렬 된 순서로 데이터를 리턴하며 정렬 순서를 선택할 인터페이스가 없습니다.

2) 사용자는 데이터를 보는 방법을 제어해야합니다.

뷰는 컨트롤러와 상호 작용하는 인터페이스 (예 : 오름차순 / 내림차순 화살표)를 제공하며 모델은 데이터에 대해 요청 된 정렬을 수행하기에 충분히 데이터를 이해합니다. 그러나 (1)과 달리 원시 데이터 풀을 정렬 할 필요는 없습니다.

두 경우 모두

뷰는 어떤 정렬 방향이 선택되었는지 표시하는 기능 외에 다른 정렬이 있음을 이해하지 못합니다. 거기에 논리를 넣지 마십시오.

작은 경고

정렬 기능 은 순전히 하나의 상황에서 뷰에서 진행될 수 있습니다 (내가 생각할 수는 있지만 더있을 수도 있습니다).

모든 데이터가 이미 뷰에 있고 정렬을 수행하기 위해 도메인 지식을 사용할 필요가없는 "멍청한"정렬입니다. 예를 들어 매우 간단한 문자열 또는 숫자 비교. 예를 들어, 결과가 여러 페이지로 나눠 질 수있는 웹 페이지의 검색 결과에서는 불가능합니다.

---

MVC 설명 에 따르면 ,

컨트롤러는 모델의보기 표시를 변경하기 위해 명령을 연관된보기로 보낼 수 있습니다 (예 : 문서를 스크롤하여). 모델 상태를 업데이트하는 명령을 모델에 보낼 수 있습니다 (예 : 문서 편집).

이에 따르면, 정렬 논리는 컨트롤러에 속합니다. 모델 데이터의 정렬 방식을 변경하면 "모델의 뷰 표시 변경"범주에 속하기 때문입니다.

편집 : 주석에서 언급 된 여러 오해를 명확히하기 위해 "정렬 논리"는 정렬을 수행하는 코드 가 아닙니다 . 정렬 을 정의 하는 코드입니다 . 정렬 논리는 개별 항목을 서로 비교하여 순서를 설정하거나 (예 :의 인스턴스를 통해 IComparator<T>) 외부 시스템에 의해 (예 :의 인스턴스를 통해) 주문에 사용되는 객체를 구성하는 논리를 포함 IOrderedQueryable<T>합니다. 이 로직은 애플리케이션의 "비즈니스"측면과 관련된 지식이 필요하기 때문에 컨트롤러에 속합니다. 정렬을 수행하는 것으로는 충분하지만 실제로 수행 하는 코드와는 별개입니다.그것. 정렬 코드는 뷰, 모델 또는 모델을 지원하는 지속성 계층 (예 : SQL 데이터베이스)에있을 수 있습니다.

---

위의 어느 것도 아닙니다. 정렬은 비즈니스 로직이며 비즈니스 로직은이 세 가지 중 하나에 속하지 않습니다. 응용 프로그램의 모든 코드가 모델, 뷰 또는 컨트롤러가되는 것은 아닙니다.

MVC 앱에서 일반적으로하는 일은 모든 비즈니스 로직을 수행하는 서비스 계층이 있다는 것입니다. 서비스 계층의 메소드에는 매개 변수가 이름이 지정된 깨끗하고 간단한 API가 있어야합니다. 그런 다음 컨트롤러에서 해당 메소드를 호출하여 모델의 데이터를 조작 할 수 있습니다.

그런 의미에서 정렬은 "컨트롤러에서"이지만 정렬을 수행하는 코드 자체는 컨트롤러에서 구현되어서는 안되며 여기서 만 호출해야합니다.

---

분명히 컨트롤러가 아님 : 메시지를보고 모델로 보내지 만 가능한 한 적은 작업을 수행해야합니다. 사용자가 정렬을 변경할 수있는 경우 해당 요청은 모델 또는 이에 대한보기를 알려 컨트롤러에 의해 처리됩니다.

순수한 View 일 경우 View 일 수 있습니다. 응용 프로그램이 정렬없이 잘 작동하면 정렬은 표현의 일부일 뿐이며보기로 이동해야합니다.

순서가 도메인의 고유 부분 인 경우 모델로 이동해야합니다.

---

• 뷰는 프리젠 테이션 로직을 포함해야하는 MVC의 일부입니다.
• 모델 계층은 비즈니스 로직이 포함 된 곳입니다.
• 컨트롤러는 사용자 입력에 따라 두 상태 만 변경합니다.

선택은 도메인 비즈니스 로직 또는 프리젠 테이션 로직의 일부라고 생각합니까?

If you were implementing a proper MVC Model2 or classical MVC pattern, then I would say that the ordering of data provided by the model layer should be triggered by the view's request to the model layer. View asks for ordered data, model layer provides it.

But, since you are using ASP.NET MVC's interpretation of MVC pattern, which is a bit different then your standard MVC - the ViewModel instance should request ordered information from the model layer (for some reason ASP.NET framework thinks that templates should be called "views" and views should be called "viewmodels" .. it's strange).

---

I would usually do it in the controller to remain in line with the pattern as per the other answers. See below for reasoning.

I've been mulling this over and reading the answers and related material and pragmatically speaking I would say it would depend on your application for instance:

Is it a medium/large application and/or has multiple UI's associated with it (i.e. a Windows App, Web interface and Phone interface).

• In this case I would probably construct a service layer and put it in the business object and then call the appropriate method from the controller.

If its a well defined single UI website and you're using something like EF Code First and you do not have or have no intention of creating a service layer and plan on using a simple out of the box Extension method to acheive it:

• In this case I'd probably put it in the controller as pragmatically its the best fit with regard to time/budget.

If its the same as the above BUT cannot be implemented with an out of the box extension method.

• I may well choose to pop it in the Model class (if its truely bespoke to that single type) as it would be more appropriate here than in a controller. If the sort could be applied to more than one class then I'd implement it in an extension method and then call it in the controller.

To sum up:

Dogmatic answer: Service Layer

Pragmatic answer: Usually the controller

---

I would suggest sorting data from a table-data that is small enough to be useful in a dropdown list-should come from the DB already sorted via the query. To me, that makes the model the place the sort is applied.

If you are determined to do the sort by hand, I think there are good arguments for using either the model or controller as your preferred spot for logic. The limitation would be your particular framework. I prefer to manage data solely in the model. I use the controller to marry data(model) and presentation(view) as I've been (self)taught.

---

Whilst I agree in principle with the idea that sorting is Business Logic because by breaking it down to it's origin you would end up with something like "The client would like the Product page to display with the images sorted by date" then it becomes clear that the sort order for data is typically not arbitrary - even if there is no sorting as that's still a business decision by omission (an empty list is still a list).

BUT... These answer don't seem to take into account the advances in ORM technology, I can only talk in relation to the Entity Framework (let's avoid an argument about whether this is true ORM, that's not the point) from Microsoft as that's what I use, but I'm sure other ORMs offer similar functionality.

If I create a Strongly Typed view for a Product class using MS MVC and the Entity Framework and there is a foreign key relationship between the Product and Image table (e.g. FK_Product_Image_ProductId) then I would out-of-the-box be able to quickly sort the images during their display using something like this in the view:

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

There was mention of a specific Business Logic layer, which I also use to perform 80% of my business logic, but I'm not going to write sort functionality into my Business Logic layer that mimics something that comes out-of-the-box from the Entity Framework.

I don't think there's a correct answer to this question, other than to say that; you should abstract complex business logic where possible but not at the cost of reinventing the wheel.

---

Assume that you have MVC website, WebForms website and a mobile application.

If you want sorting to be consistent between these presentation layers, then I'd say sort outside of the presentation layer. Service would be a good candidate.

Otherwise, I would store that logic in a view model. Why? Because it'll be reusable and easily testable.

---

Out of the three you have listed, I would say that it belongs in the controller. I don't really like placing this sort of logic in the controller, though. I usually create a service layer that the controller communicates with that will be responsible for communicating with the data store and handling sorting logic. For small applications it is fine sitting in the controller, though.

---

This is a question asked with the asp.net in mind, but since somebody did mention Rails, I thought it would be interesting to consider the problem in that context. In Rails, it is natural and pretty common to perform the sorting along with the retrieval as a controller action, since the framework and ActiveRecord/ActiveQuery api provisions for it. On the other hand, it is possible to define some sort of custom sort order for static items and put that in the model to be used by the controller, so the model can play a part in the sorting logic even though it does not carry out the operation directly. Whatever it is, it can be safe to say that putting the sort logic in the view is generally frown upon.

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

참고 URL : https://stackoverflow.com/questions/11969964/should-sorting-logic-be-placed-in-the-model-the-view-or-the-controller