т. е. Является ли MVP лучшим выбором, когда MVC не подходит?
Я подумал, что задам этот вопрос здесь, так как уверен, что есть и такие, как я, которые не могут позволить себе роскошь заниматься проектом с нуля и хотят провести рефакторинг пользовательского интерфейса веб-форм, чтобы лучше отделить презентацию от бизнес-объектов. .
Я работаю над устаревшим приложением, которому поручено добавить относительно небольшие дополнительные требования, улучшения и исправления ошибок.
Та часть приложения, которую я здесь рассматриваю, может быть охарактеризована как пользовательский интерфейс для набора операций CRUD над бизнес-объектами, которые сохраняются в реляционной базе данных.
Существующий пользовательский интерфейс использует элемент управления MultiView для перехода между редактированием связанных бизнес-объектов (ассоциаций один-один или один-многие/родитель-потомок). Да, именно так - все на одной странице. К сожалению, пользовательские элементы управления используются очень редко, поэтому разметка и программный код занимают сотни строк.
В каждом представлении FormView управляет CRUD над бизнес-объектами через различные ObjectDataSource. В ItemTemplate каждого FormView различные серверные элементы управления привязываются к полям или методам в ObjectDataSource.
Я хотел бы ввести большее разделение задач и вывести часть кода из кода программной части Page.
Мои исследования до сих пор подсказывают мне, что я мог бы рассмотреть:
Использовать разновидность Model View Presenter; более конкретно - используйте ObjectContainerDataSource от Web Client Software Factory, чтобы упростить переход между текущим пользовательским интерфейсом и набором новых классов Presenter.
Создайте заново с нуля с помощью MVC-фреймворка (не вариант).
Оставь в покое; шаблон MVP оправдан только в том случае, если мне нужно повторно использовать мою презентацию в разных сценариях пользовательского интерфейса?
Если я соглашусь с (3), я все равно хотел бы знать, как начать рефакторинг для лучшего разделения представления.
Что бы вы сделали? любые другие идеи, полученные с благодарностью...
Вот еще предыстория, кому интересно:
Домен находится в фармацевтических исследованиях, но это совершенно не имеет значения, и вы можете думать об этом как о довольно типичном направлении бизнеса — пользовательской конфигурации семейства параметров, которые формируют условия работы другой части приложения.
Уровень бизнес-объектов уже построен очень последовательным образом. Хотя мне это может не нравиться, я не могу обязательно оправдывать его изменение. Каждый объект представляет собой собственный репозиторий/объект доступа к данным, поскольку существуют статические методы для «получения по идентификатору» и «получения списка по критерию». По возможности общие операции реализуются в абстрактном базовом классе. Каждый бизнес-объект делегирует работу по доступу к данным на уровень доступа к данным, который использует механизмы фабрики поставщиков ADO.NET 2.0, чтобы оставаться относительно абстрагированным от конкретного поставщика. В этом отношении у него много общего с любым приложением, использующим блок приложений для доступа к данным из корпоративной библиотеки Microsoft.
В NUnit написаны довольно исчерпывающие интеграционные тесты, которые настраивают тестовую базу данных с нуля, поэтому их запуск занимает целую вечность, но, по крайней мере, они проверяют, что все работает должным образом (во всяком случае, в какой-то момент в прошлом ;-). Настоящего модульного тестирования почти нет (пока).
