Я написал портал ASP.NET WebForms для клиента. Проект как бы развивался, а не был должным образом спланирован и структурирован с самого начала. Следовательно, весь код объединяется в одном проекте и без каких-либо слоев. Теперь клиент доволен функциональностью, поэтому я хотел бы провести рефакторинг кода, чтобы быть уверенным в выпуске проекта. Поскольку существует много разных способов проектирования архитектуры, я хотел бы высказать несколько мнений о наилучшем подходе.
ФУНКЦИОНАЛЬНОСТЬ
Портал позволяет администраторам настраивать шаблоны HTML. Другие ассоциированные «партнеры» смогут отображать эти шаблоны, добавив код IFrame на свой сайт. В рамках этих шаблонов клиенты могут регистрироваться и приобретать продукты. API был реализован с использованием WCF, что позволяет внешним компаниям также взаимодействовать с системой. Раздел администратора позволяет администраторам настраивать различные функции и просматривать отчеты для каждого партнера. Система рассылает счета и уведомления по электронной почте клиентам.
СОВРЕМЕННАЯ АРХИТЕКТУРА
В настоящее время он использует EF4 для чтения / записи в базу данных. Объекты EF используются непосредственно в файлах aspx. Это облегчило быструю разработку, пока я писал сайт, но, вероятно, недопустимо поддерживать его таким, поскольку он тесно связывает БД с пользовательским интерфейсом. Специальная бизнес-логика была добавлена к частичным классам объектов EF.
ВОПРОСОВ
Целью рефакторинга будет сделать сайт масштабируемым, легко обслуживаемым и безопасным.
Какая архитектура будет лучше для этого? Пожалуйста, опишите, что должно быть на каждом слое, должен ли я использовать шаблон DTO / POCO / Active Record и т. Д.
Существует ли надежный способ автоматической генерации DTO / BO, чтобы любые будущие усовершенствования были простыми для реализации, несмотря на дополнительные уровни?
Было бы выгодно преобразовать проект из WebForms в MVC?
Ответы:
Шаблон ASP.NET MVP - лучшая архитектура для долгосрочного веб-приложения ASP.NET. Он вступает в игру с концепцией «разделения интересов», которая де-факто является тенденцией позади моделей MV *.
Вопрос о том, зачем его использовать? - подробно рассмотрено в этом посте - ASP.NET MVP
источник
источник
Как отметил ЭльЮсубов, модель 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 звучит запутанно, просто сконцентрируйтесь на рефакторинге и знайте, что смысл всего этого - максимизировать повторное использование кода. С тех пор нет повторения. Это СУХОЙ принципал .
источник