Лучшая архитектура для приложения ASP.NET WebForms

Я написал портал ASP.NET WebForms для клиента. Проект как бы развивался, а не был должным образом спланирован и структурирован с самого начала. Следовательно, весь код объединяется в одном проекте и без каких-либо слоев. Теперь клиент доволен функциональностью, поэтому я хотел бы провести рефакторинг кода, чтобы быть уверенным в выпуске проекта. Поскольку существует много разных способов проектирования архитектуры, я хотел бы высказать несколько мнений о наилучшем подходе.

ФУНКЦИОНАЛЬНОСТЬ

Портал позволяет администраторам настраивать шаблоны HTML. Другие ассоциированные «партнеры» смогут отображать эти шаблоны, добавив код IFrame на свой сайт. В рамках этих шаблонов клиенты могут регистрироваться и приобретать продукты. API был реализован с использованием WCF, что позволяет внешним компаниям также взаимодействовать с системой. Раздел администратора позволяет администраторам настраивать различные функции и просматривать отчеты для каждого партнера. Система рассылает счета и уведомления по электронной почте клиентам.

СОВРЕМЕННАЯ АРХИТЕКТУРА

В настоящее время он использует EF4 для чтения / записи в базу данных. Объекты EF используются непосредственно в файлах aspx. Это облегчило быструю разработку, пока я писал сайт, но, вероятно, недопустимо поддерживать его таким, поскольку он тесно связывает БД с пользовательским интерфейсом. Специальная бизнес-логика была добавлена ​​к частичным классам объектов 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 против MVC

1. Используйте шаблон MVP для отдельных и логики и пользовательского интерфейса, чтобы в будущем вы могли перейти на другую технологию пользовательского интерфейса, повторно используя существующую логику
2. Используйте шаблон репозитория между BL и DAL, чтобы вы могли перейти на любую RDBS, повторно используя бизнес-логику
3. принесите отдельные слои (Dlls) для BO и DAL, что сводит к минимуму техническое обслуживание.

Как отметил ЭльЮсубов, модель MVP может быть отличной.

Ключевой концепцией является удаление большей части или всей вашей логики из кода. Логика не должна быть привязана к странице. Что если вам нужно повторно использовать логику с одной страницы на другую? У вас будет соблазн копировать и вставлять. Если вы делаете это, то ваш проект станет ремонтопригодным.

Итак, для начала начните рефакторинг вашей логики из выделенного кода и поместите ее на бизнес-уровень. Если вам удалось извлечь всю логику из кода, то вы могли бы реализовать необходимые интерфейсы, чтобы быть настоящим MVP.

Также убедитесь, что ваш доступ к данным отделен от вашей бизнес-логики. Создайте слой данных и также начните рефакторинг. Поскольку вы используете EF4, это меньше проблем, так как EF уже должен иметь этот конец отдельно. Вы должны быть в состоянии легко переместить все ваши EF-файлы в другой проект и просто добавить ссылку на проекты, которые в этом нуждаются. Дополнительное преимущество заключается в том, что вам может потребоваться ссылаться на вашу модель данных в других проектах.

Чтобы избежать перегрузки, выполняйте рефакторинг постепенно. Всякий раз, когда вы касаетесь фрагмента кода, подумайте о рефакторинге кода вокруг него. Если вы сделаете это, со временем ваш проект станет более понятным.

редактировать

Вы спрашивали о том, чтобы код наследовал класс бизнес-логики. Это не может быть сделано, потому что код "is-a" страницы. C # не допускает множественного наследования, поэтому класс code-behind не может быть одновременно страницей и пользовательским объектом. Вы должны концептуально отделить логику. Вероятно, дело в том, что код вашего кода делает много разных вещей. Класс должен делать одно и только одно. Попробуйте и подумайте, как вы можете концептуально извлечь существующую функциональность. Например, допустим, у вас есть страница регистрации, и вы собираете информацию о пользователях. Вероятно, у вас есть кнопка с именем register и событие нажатия, связанное с этой кнопкой. В этом случае вы сохраняете пользовательскую информацию и выполняете любую необходимую вам обработку. Вы можете создать объект регистрации для обработки всей этой логики.

Это не только более чистое разделение, но и способ самостоятельного документирования вашего кода. Когда кто-то читает ваш код, он видит, что вы вызываете объект Registration, чтобы вы точно знали, что происходит.

Если вы хотите строго следовать шаблону MVP, вместо передачи параметров в объект регистрации, программный код будет реализовывать интерфейс. Реализация интерфейса по существу отобразит все объекты вида (текстовое поле и т. Д.) На интерфейс. например, открытая строка FirstName {get {return txtFirstName.Text; }}

Как только это будет сделано, вы можете передать страницу объекту Regisration.

Registration.RegisterUser (это);

И этот метод RegisterUser будет принимать интерфейс в качестве параметра

public bool RegisterUser (пользователь IUser) {user.FirstName ...}

открытый интерфейс IUser {открытая строка FirstName; }

Если этот MVP звучит запутанно, просто сконцентрируйтесь на рефакторинге и знайте, что смысл всего этого - максимизировать повторное использование кода. С тех пор нет повторения. Это СУХОЙ принципал .