"동일한 프로젝트에 컨트롤러/뷰가 있고, 모든 클래스가 별도의 클래스 라이브러리에 있습니다"라는 방식은 직관적이지 않습니다. 필자는 세로로, 즉 관련 컨트롤러/뷰/별도의 프로젝트에서 뷰 모델을 갖는 것을 선호합니다.MVC 프로젝트 구성
그래서 인터넷을 검색하여 일부 (많은 사람들이 아닌) 사람들이 지역 기능을 사용하고 있음을 알았지 만 라우팅을 할 때 고통 스럽습니다.
컨트롤러/뷰/뷰 모델을 영역 대신 별도의 프로젝트로 넣을 수없는 이유는 무엇입니까? 나는 그것을 할 수 없습니까? 아니면 성능을 저하시키지 않으므로 아무도 그것을 사용하지 않습니까?
실제로보기 모델과 컨트롤러를 다른 프로젝트로 이동할 수 있습니다.
상자에서 사용할 수있는 것은 아닙니다.
ViewEngine, 컨트롤러 팩토리 등 몇 가지 MVC 인프라 클래스를 직접 구현해야합니다.이 방법을 사용하면 프로젝트를 새 버전의 ASP로 마이그레이션하는 것이 매우 어려울 것입니다. NET MVC와 Microsoft에서 제공하는 클래스는 잘 테스트되고 최적화되었습니다.
구조는 원하는 해결책을 제공합니다. 모든 것이 원하는대로 작동하도록 구성 할 수 있습니다. 또한 솔루션을 구조화하는 방법은 성능에 영향을 미치지 않아야합니다.
솔루션을 관용적 인 기본 방식으로 구성하는 것이 훨씬 더 간단 할 것입니다. MVC의 다른 사용자는 이미 기본 방법을 잘 알고 있으므로 쉽게 협업 할 수 있습니다. 이 일지라도 다른 구조가 더 좋다고 느낄지라도 기본 구조를 허용하면 큰 도움이됩니다.
[구성에 대한 협약] (http://en.wikipedia.org/wiki/Convention_over_configuration) - MVC의 백본으로 계층 구조가 지정됩니다. –