MVC 디자인 패턴

MVC 디자인 패턴에 대해 많이 읽었지 만 일부는 여전히 나에게 불분명합니다. "모델"은 데이터 및 비즈니스 로직 용이며 "보기"는 프레젠테이션 용이며 "컨트롤러"는 "모델"을 사용하고 "뷰"(즉 C는 M과 V 사이의 통신 채널)를위한 것입니다.MVC 디자인 패턴

지금, 내가 해결하려면 다음과 같은 문제가있다 :

문제 : 웹 응용 프로그램이 사용자로부터 입력으로 노드의 목록을합니다. 그런 다음 모델을 사용하여 해당 노드에서 그래프 (즉, 데이터 구조 그래프가 아니라 x-y 그래프가 아님)를 만듭니다 (데이터베이스 사용).

그런 다음 Dijkstra의 알고리즘을 사용하여 그래프의 시작 노드에서 끝 노드까지의 최단 경로를 찾습니다. 모델이나 컨트롤러에서 Dijkstra의 알고리즘을 사용합니까?

"최단 경로"자체가 데이터이기 때문에 모델 레이어를 사용해야한다고 생각합니다.

가끔은 모델 (그래프 및 노드 목록)을 사용하여 컨트롤러에 넣어야한다고 생각합니다.

누구든지 나에게 올바른 대답을 줄 수 있습니까? 지금은 모델 레이어에 Dijkstra의 알고리즘을 구현할 것입니다.

출처

2012-02-21 coolscitist

네 말이 맞습니다. Dijkstra의 알고리즘을 모델에 넣어야합니다. 이유는 다른 알고리즘을 사용하여 내일 최단 경로를 찾을 수 있기 때문에 컨트롤러를 변경할 필요가 없으며 알고리즘을 구현하는 클래스의 로직을 변경하기 만하면됩니다. 그리고이 알고리즘의 결과는보기에 통합되어야합니다. 당신이 모델의 일부를 사용하는 경우 모든 모델은

하고 거기 sorest 경로 알고리즘 컨트롤러 호출에 의해 제어 될 것입니다 후 있기 때문에 실행 시간을 증가 때문 컨트롤러 부분 로 이동됩니다

출처

2012-02-21 11:13:12

아주 좋은 이유입니다. 나는 그렇게 생각하지 않았다. 감사합니다 – coolscitist

내 질문에 대한 또 다른 회신이 있었지만 지금 어디로 갔는지 모르겠습니다. DIJKSTRA의 알고리즘은 CONTROLLER에 있어야하며 그 결과, SHORTEST PATH는 MODEL이어야합니다. 나는 그것이 올바른 대답이라고 생각한다. – coolscitist

나는 그렇게 생각하지 않는다. 알고리즘이나 결과가 컨트롤러에 없어야합니다. 컨트롤러는 뷰와 모델간에 대화하는 데 도움이됩니다. 그리고 다시 알고리즘의 단계 (실제 구현)가 모델에 있어야한다고 말했습니다. –

내 개인 제안 어떤 우리가 가진 모든 데이터베이스 수정 그냥 알고리즘을 기반으로 데이터와 재생

그래서 내 개인적인 느낌은 컨트롤러 대신 모델과 이동

감사

출처

2012-02-21 11:18:02

안에 그것을 구현합니다 내 질문에 대한 또 다른 회신이 있었지만 지금 어디로 갔는지 모르겠습니다. DIJKSTRA의 알고리즘은 CONTROLLER에 있어야하며 그 결과, SHORTEST PATH는 MODEL이어야합니다. 나는 그것이 정답이라고 생각한다. 컨트롤러가 – coolscitist

인 이유. 컨트롤러는 통신 채널이 로직을 구현하지 않아야합니다. 구현은 모델 – Tassadaque

에 있어야합니다. 모델에 알고리즘을 구현합니다. – coolscitist

질문은 왜 컨트롤러가 아니라 모델입니다. 그것의 설계 질문은 코딩 질문 이상입니다. 그것은 컨트롤러와 모델에서 작동합니다. 그러나 앞으로 하나 이상의 컨트롤러가 필요하다면 (예를 들어 다른 알고리즘을 최단 경로로 사용하는 경우) 런타임에 컨트롤러를 선택하기 위해 모델이 필요하다면 컨트롤러에 있어야합니다. 알고리즘이 "컨트롤러"뭔가 다른 경우 모델에 있어야합니다. 이 알고리즘을 사용하여 최단 경로를 사용하고 싶을 수도 있지만 나중에 다른 유형의 데이터를 사용하려고합니다. 그러면 데이터 조작자가 컨트롤러에 있어야합니다.

간단히 말해서 미래와 디자인을 생각하고 컨트롤러에 넣지 마십시오. 왜냐하면 그 알고리즘은 "변화"가 필요하기 때문입니다.

변경 사항이 여기에 있습니다. 새로운 기능이 제품에 추가되면서 앞으로 변경 될 것으로 예상되는 사항은 무엇입니까?

출처

2012-02-21 11:44:10 Siddharth

모델에 알고리즘을 구현합니다. 실제로는 단지 대학 과제입니다. 하지만 이번에는 코드에서 잘못된 판례를 들여 놓지 않을 것입니다. 나는 나 자신에게 엄격 해지고있다. – coolscitist

@Robik "대학 과제"보다는 미래에 예상되는 "변화"에 기반하여 결정하는 것이 중요합니다. 디자인 패턴 책을 읽으면 "변화"에 중점을 둡니다. 또한 그들은 그 사례가 단지 "지침"이라는 충고를한다. 생각해 내다. "쉽게 변경할 수있는"코드를 작성하면 "변경되지 않은"영역에서 더 많은 테스트가 수행되어서는 안되며 변경되지 않은 영역에 결함이 생기면 좋은 코드를 작성한 것입니다. 따라서 " 내일의 변화 "코드를 쓸 곳/장소를 결정하기 전에 – Siddharth

좋습니다. 내가 전문적으로 일을 시작할 때 실제 느낌을받을 수 있습니다. – coolscitist

개인적으로 알고리즘을 응용 프로그램의 컨트롤러 부분에 넣고 전략 패턴을 사용하여 컨트롤러가 런타임에 적절한 알고리즘을 선택하도록합니다. 지금까지 알고리즘이 하나만있는 경우 전략 패턴과 함께 하나의 알고리즘 만 선택됩니다.

이렇게하면 모델이 응용 프로그램의 상태를 나타내며 비즈니스 논리가 명확하게 유지됩니다. 또한 전략 패턴으로 인해 컨트롤러가 특정 알고리즘 구현과 독립적으로 유지되며 나중에 비교적 쉽게 다른 알고리즘을 사용하도록 응용 프로그램을 확장 할 수 있습니다.

다른 알고리즘 구현을 사용하기 위해 응용 프로그램을 확장 할 필요가 없다고 확신하는 경우에는 전략 패턴없이 수행 할 수 있습니다.

출처

2013-03-15 14:14:59 sdcr

헤드 퍼스트 서블릿과 JSP를 읽으면 로직이 모델에 가장 잘 보관되어 있다는 것을 알게 될 것입니다. 왜 내가 그렇게 말합니까 내일 : 애플리케이션의 뷰 레이어를 변경한다고 생각하면 모델을 준비해야합니다. 예 : MVC의 장점은 유연성을 제공한다는 것입니다. 내일은 내 응용 프로그램이 데스크탑에서 웹으로 또는 그 반대로 실행되기를 원합니다. 나는 모든 논리를 별도로 작성할 수 있습니다. Strategy Design Pattern은 확장성에 도움이되는 것은 좋지만 다시 Model에 쓰는 로직을 갖기를 바랍니다.

출처

2016-04-20 17:06:03

MVC 디자인 패턴

답변

관련 문제