ASP.NET WebForms 응용 프로그램을위한 최고의 아키텍처

클라이언트 용 ASP.NET WebForms 포털을 작성했습니다. 이 프로젝트는 처음부터 올바르게 계획되고 구조화되는 것이 아니라 진화되었습니다. 결과적으로 모든 코드는 동일한 프로젝트 내에서 계층없이 뭉쳐집니다. 클라이언트는 이제 기능에 만족하기 때문에 프로젝트 릴리스에 대해 확신 할 수 있도록 코드를 리팩터링하려고합니다. 아키텍처를 디자인하는 방법은 여러 가지가 있으므로 최선의 접근 방식에 대한 의견을 갖고 싶습니다.

기능성

관리자는 포털을 통해 HTML 템플릿을 구성 할 수 있습니다. 다른 관련 "파트너"는 사이트에 IFrame 코드를 추가하여 이러한 템플릿을 표시 할 수 있습니다. 이러한 템플릿 내에서 고객은 제품을 등록하고 구입할 수 있습니다. 외부 회사가 시스템과 인터페이스 할 수 있도록 WCF를 사용하여 API가 구현되었습니다. 관리자 섹션에서는 관리자가 다양한 기능을 구성하고 각 파트너에 대한 보고서를 볼 수 있습니다. 시스템은 고객에게 송장 및 이메일 알림을 보냅니다.

현재 건축

현재 데이터베이스를 읽고 쓰는 데 EF4를 사용하고 있습니다. EF 개체는 aspx 파일 내에서 직접 사용됩니다. 이것은 사이트를 작성하는 동안 빠른 개발을 촉진했지만 DB와 UI를 밀접하게 연결하므로 사이트를 유지하는 것은 용납되지 않을 것입니다. EF 객체의 일부 클래스에 특정 비즈니스 로직이 추가되었습니다.

질문

리팩토링의 목표는 사이트를 확장 가능하고 쉽게 유지 관리하고 안전하게 만드는 것입니다.

1. 어떤 아키텍처가 가장 좋을까요? DTO / POCO / Active Record 패턴 등을 사용해야하는지 각 계층에 무엇이 있어야하는지 설명하십시오.

2. 추가 계층에도 불구하고 향후 개선 사항을 쉽게 구현할 수 있도록 DTO / BO를 자동 생성하는 강력한 방법이 있습니까?

3. 프로젝트를 WebForms에서 MVC로 변환하는 것이 유리합니까?

ASP.NET MVP 패턴 은 장기 ASP.NET 웹 양식 응용 프로그램에 가장 적합한 아키텍처입니다 . MV * 패턴의 배경이되는 "문제의 분리"개념이 적용되었습니다.

사용 이유 에 대한 질문 ? -이 게시물의 상세 내용 -ASP.NET MVP

• ASP.NET Webforms 응용 프로그램 테스트 시작
• MVP와 MVC의 균형
• 혼란의 끝 : MVP vs MVC

1. 별도 및 논리 및 UI에 MVP 패턴을 사용하므로 향후 기존 논리를 재사용하는 다른 UI 기술로 이동할 수 있습니다.
2. 비즈니스 로직을 재사용하는 RDBS로 변경할 수 있도록 BL과 DAL 사이의 저장소 패턴을 사용하십시오.
3. BO와 DAL에 별도의 레이어 (Dll)를 가져와 유지 관리를 최소화합니다.

ElYusubov가 언급했듯이 MVP 패턴은 훌륭 할 수 있습니다.

핵심 개념은 코드 숨김에서 대부분 또는 모든 논리를 제거하는 것입니다. 논리는 페이지에 바인딩되지 않아야합니다. 한 페이지에서 다른 페이지의 논리를 다시 사용해야하는 경우 어떻게합니까? 복사하여 붙여 넣기를 원할 것입니다. 이 작업을 수행하면 프로젝트를 유지 관리 할 수있게됩니다.

따라서 초보자는 코드 숨김에서 논리를 리팩토링하여 비즈니스 계층에 넣습니다. 코드 숨김에서 모든 논리를 얻을 수 있다면 진정한 MVP가되기 위해 필요한 인터페이스를 구현할 수 있습니다.

또한 데이터 액세스가 비즈니스 로직과 분리되어 있는지 확인하십시오. 데이터 계층을 생성하고 그 끝에서 리팩토링을 시작하십시오. EF4를 사용하고 있기 때문에 EF는 이미이 끝이 별도로 있어야하기 때문에 문제가되지 않습니다. 모든 EF 파일을 다른 프로젝트로 쉽게 이동하고 필요한 프로젝트에 대한 참조를 추가 할 수 있어야합니다. 추가 이점은 다른 프로젝트에서 데이터 모델을 참조해야 할 수도 있다는 것입니다.

압도 당하지 않도록 한 번에 조금씩 리 팩터하십시오. 코드를 만질 때마다 코드 리팩토링을 고려하십시오. 이렇게하면 시간이 지남에 따라 프로젝트를 유지 관리하기가 더 쉬워 질 수 있습니다.

편집하다

코드 뒤에 비즈니스 로직 클래스를 상속하도록 요청했습니다. "is-a"페이지 뒤에있는 코드 때문에이 작업을 수행 할 수 없습니다. C #은 다중 상속을 허용하지 않으므로 코드 숨김 클래스는 페이지 및 사용자 지정 개체가 될 수 없습니다. 논리를 개념적으로 분리해야합니다. 아마도 코드 숨김의 코드가 많은 다른 일을하는 경우 일 것입니다. 수업은 한 가지 일만해야합니다. 기존 기능을 개념적으로 끌어낼 수있는 방법에 대해 생각해보십시오. 예를 들어 등록 페이지가 있고 사용자 정보를 수집하고 있다고 가정합니다. register라는 버튼과 해당 버튼과 관련된 클릭 이벤트가있을 수 있습니다. 이 경우 사용자 정보를 저장하고 필요한 처리를 수행합니다. 모든 해당 논리를 처리하기 위해 Registration 객체를 만들 수 있습니다.

이것은 명확하게 분리 될뿐만 아니라 코드를 자체 문서화하는 방법이 될 수도 있습니다. 누군가 코드를 읽으면 등록 객체를 호출하는 것을 볼 수 있으므로 정확히 무슨 일이 일어나고 있는지 알 수 있습니다.

MVP 패턴을 엄격하게 따르려면 매개 변수를 Registration 객체에 전달하는 대신 코드 숨김이 인터페이스를 구현합니다. 인터페이스의 구현은 본질적으로 모든 뷰 객체 (텍스트 필드 등)를 인터페이스에 매핑합니다. 예를 들어 공개 문자열 FirstName {get {return txtFirstName.Text; }}

완료되면 페이지를 Regisration 객체로 전달할 수 있습니다

등록. 등록 사용자 (this);

이 RegisterUser 메소드는 인터페이스를 매개 변수로 사용합니다.

공개 bool RegisterUser (IUser 사용자) {user.FirstName ...}

공용 인터페이스 IUser {공용 문자열 FirstName; }

이 MVP가 혼란스럽게 들리면 리팩토링에 초점을 맞추고 코드 재사용을 극대화하는 것이 중요하다는 것을 아십시오. 그 이후로 자신을 반복 할 필요는 없습니다. 그것이 DRY 교장 입니다.