나는 누군가가 도우미 클래스 나 메서드를 별도의 어셈블리에 저장하고 있는지, 그리고 이유는 단지 그것들을 깨끗하게 관리하기 위해서인지를 알고 싶다. 나는 MVC 프로젝트 내에서 도우미 폴더를 사용하는 것에 대한 많은 게시물을 보았고, 그로 인해 사람들이 자신의 프로젝트로 물리적으로 이것을 분리하는 대신 App_code 폴더를 사용하는 ASP.NET의 지저분한 옛날로 돌아 왔습니다. .도우미 클래스를 별도의 어셈블리에 저장합니까?
마찬가지로 실제 아키텍처를 수행하는 사람은 MVC 웹 어셈블리의 일부 폴더에 모델을 넣지 않습니다. 그들은 MyApp.DataLayer 어셈블리 또는 MyApp.Models 또는 이와 유사한 항목에 들어갑니다.
프로젝트를 사용하여 웹 또는 응용 프로그램의 여러 레이어를 구분합니다. 비즈니스 규칙을 더 잘 존중할 수있게 해줍니다. 또한 내가 변화를 원한다면 어디로 가야하는지 쉽게 추적 할 수 있습니다.
그러나 나는 사람들이 솔루션의 레이어에 레이블을 붙이는 폴더를 사용하는 것을 보았습니다.하지만 좀 지저분하다고 생각합니다.
우리는 별도의 프로젝트에 일부 도우미가 있고 웹 프로젝트에는 일부 도우미가 있습니다. 일부 헬퍼가 웹 프로젝트 자체에서 정의한 추상화를 사용해야한다는 것을 알게 될 것입니다. 웹 프로젝트에 대한 참조가있는 다른 프로젝트가있는 것이 바람직하지 않기 때문에 이러한 헬퍼를 웹 프로젝트에 넣어야합니다. App_Code를 사용하는 것과 같은 것으로 간주하지 않습니다. IDE 내에서 컴파일 할 때 컴파일되는 파일로서 App_Code에 적용되는 특별한 "마법"은 없습니다.
사실 App_Code와 같은 의미는 아닙니다. 즉, 웹 응용 프로그램의 일부 하위 폴더에있는 별개의 어셈블리에있는 모든 것을 뼈대에 넣는 개념을 말합니다. – PositiveGuy
나는 이해한다. 나의 첫 성향은 그것들을 별개의 집회에 너무 넣는 것이었다. 하지만 그건 잘못되었습니다. 처음으로 웹 프로젝트에있는 클래스를 사용하는 HTML 도우미를 만들어야 할 때, 필자는 적어도 제 상황과 아마도 많은 상황에서 헬퍼가 웹 프로젝트에 가장 적합하다는 것을 깨달았습니다. –
네,하지만 물론 다른 어셈블리에 공통적 인 이유로
그러나 모든 혼란 다른 현명한,에 헬퍼 클래스를 유지하는 것이 좋습니다 그들이 속한 곳.
특정 프로젝트에만 해당하는 도우미에 대해 다소 이야기하고 있습니다. 나는 여전히 물리적 인 것들을 분리하는 것이 일 (발견 능력)을 발견하는 것이 훨씬 쉬우 며 유지 보수 및 웹 애플 리케이션의 혼란을 줄이는 훨씬 전문적인 방법을 찾는다 고 생각합니다. – PositiveGuy
작성한 모든 도우미가 모든 mvc 프로젝트에서 재사용 할 수있는 것은 아닙니다. – PositiveGuy
예, 비즈니스 레이어의 일부이기 때문에 가능합니다. 두 개의 큰 보수 :
이 유틸리티 함수와 헬퍼 클래스가 전체 시스템의 가장 많이 사용되는 구성 요소의 일부가 될 가능성이 명심
내가 만드는 대부분의 도우미는 일반적으로 레이어마다 다르기 때문에 필요한 헬멧을 어셈블리와 함께 유지하는 경향이 있습니다. 특정 프로젝트 도우미 클래스를 많이 저장하는 다른 프로젝트를 추가 할 이유가 없습니다.
한 가지를 명확히 할 수 있습니까? HTML 도우미 확장 메서드와이 메서드가 포함 된 클래스에 대해 구체적으로 이야기하고 있습니까?아니면 응용 프로그램을 만드는 과정에서 생성되는 다양한 "도우미 클래스"에 대해 더 광범위하게 이야기하고 있습니까? 게시물에 "도우미 클래스"라고 표시되지만 많은 사람들이 "HTML 도우미 메서드"(및 이러한 메서드가 포함 된 정적 클래스)를 배치하는 "도우미"폴더도 언급됩니다. –