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

10

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

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

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

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

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

ВОПРОСОВ

Целью рефакторинга будет сделать сайт масштабируемым, легко обслуживаемым и безопасным.

  1. Какая архитектура будет лучше для этого? Пожалуйста, опишите, что должно быть на каждом слое, должен ли я использовать шаблон DTO / POCO / Active Record и т. Д.

  2. Существует ли надежный способ автоматической генерации DTO / BO, чтобы любые будущие усовершенствования были простыми для реализации, несмотря на дополнительные уровни?

  3. Было бы выгодно преобразовать проект из WebForms в MVC?

стек человек
источник
1
Выпуск рано, выпуск часто. Я полагаю, что вашему клиенту может быть наплевать, если у вас нет реальных бизнес-проблем (например, это небезопасно). Возможно, вам следует немного привести себя в порядок (убедиться, что он переносим) и выпустить, а затем принять это как долгосрочную инициативу - превратиться в MVC или подобное.
gahooa
2
Не меняйте технологию вашего рабочего проекта на новую технологию XYZ только потому, что она есть, особенно если ваш проект работает нормально, как есть. Если это работает, не ломайте это. Бизнес не заботится о коде. Функциональность - это все, что имеет значение в конце дня.
NoChance
Хорошо, это правда, однако моя проблема в том, что после его выпуска будет сложнее провести рефакторинг из-за риска его нарушения, когда ставки намного выше. Таким образом, мы застряли с кодом, который не так удобен в обслуживании и сложнее в отладке и т. Д. У меня было искушение выучить / преобразовать в MVP, но это выглядело слишком много работы. До сих пор я только что преобразовал его в уровни DAL, Domain, UI, которые кажутся более организованными, но в то же время допускают неизбежные RAD, которые понадобятся, пока проект молод. Однажды, если необходимо, я могу перейти на MVP или MVC, я полагаю - после того, как у меня будет достаточно времени, чтобы узнать, как все это работает.
стек человек
То, что еще кажется грязным, это: 1) Объекты EF в пользовательском интерфейсе (код файлов на уровне пользовательского интерфейса)
стек
(2) Бизнес-логика в расширенных объектах EF, которая должна идти на уровне DAL (не предполагалось, что частичные классы должны быть в одной сборке) (3) Бизнес-логика в файлах aspx.cs на уровне пользовательского интерфейса. Тем не менее, кажется, что в архитектуре часто возникают компромиссы, но это, безусловно, шаг вперед. Я чувствую, что это приемлемо для 1-го выпуска, и со временем мы можем пересмотреть наш подход. Спасибо всем за помощь. Хорошо получить немного руководства, поскольку эта область настолько субъективна.
стек человек

Ответы:

5

Шаблон ASP.NET MVP - лучшая архитектура для долгосрочного веб-приложения ASP.NET. Он вступает в игру с концепцией «разделения интересов», которая де-факто является тенденцией позади моделей MV *.

Вопрос о том, зачем его использовать? - подробно рассмотрено в этом посте - ASP.NET MVP

Юсубы
источник
Проблема в том, что для рефакторинга проекта в MVC потребовалось бы много работы ... если бы я оставил его как приложение WebForms с уровнем домена (сначала код, POCO), уровнем доступа к данным (только для контекста БД) и пользовательским интерфейсом, Вы считаете это приемлемым дизайном для производства? Позже мы могли бы рассмотреть вопрос о преобразовании его в MVC, я полагаю.
стек человек
Ну, это шаблон MVP (модель-представление-презентатор), а не MVC (модель-представление-контроллер).
Юсубов
1
ой прости - я неправильно прочитал Спасибо - буду читать про дизайн MVP.
стек человек
нет проблем, я надеюсь, вы найдете то, что вы ищете :)
Юсубов
Кажется, что преобразование в MVP также будет серьезным изменением. Клиент хочет выпустить очень скоро, так что вы думаете, что вышеупомянутая архитектура DAL / DA / UI (хотя и не такая идеальная, как MVP) будет приемлемой для этого типа приложений? Затем после релиза мы можем посмотреть на переход на MVP в v2.
стек человек
1
  1. Используйте шаблон MVP для отдельных и логики и пользовательского интерфейса, чтобы в будущем вы могли перейти на другую технологию пользовательского интерфейса, повторно используя существующую логику
  2. Используйте шаблон репозитория между BL и DAL, чтобы вы могли перейти на любую RDBS, повторно используя бизнес-логику
  3. принесите отдельные слои (Dlls) для BO и DAL, что сводит к минимуму техническое обслуживание.
Аруначалам
источник
Не уверен, почему кто-то вниз проголосовал за этот вопрос. Если честно, это самый лаконичный ответ. +1
Грег Бургхардт
0

Как отметил ЭльЮсубов, модель 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 звучит запутанно, просто сконцентрируйтесь на рефакторинге и знайте, что смысл всего этого - максимизировать повторное использование кода. С тех пор нет повторения. Это СУХОЙ принципал .

кодировщик
источник
Спасибо за ваши полезные советы. Да, я, конечно, был немного ошеломлен этим. Мне кажется, что MVC будет лучшим шаблоном для использования, но MVP будет проще достичь и станет следующим лучшим шаблоном. Я всегда использовал код позади файлов, поэтому всегда ломал голову над тем, как можно отделить бизнес-логику от представления ... поэтому я должен иметь возможность по существу переместить мои файлы .aspx.cs на уровень домена и иметь оператор наследования в aspx ? Конечно, заканчивая 3 слоями, я чувствую себя комфортно с выпуском 1-й версии - тогда я могу улучшить ее оттуда.
стек человек
Я отвечу на ваш комментарий в моем ответе. Не стесняйтесь высказать мой ответ, если вы нашли его полезным
кодер