MVP / MVC против традиционного многоуровневого подхода для приложений winform

Question

У нас большой набор приложений, большинство из которых C # 1.1, но по крайней мере 10 основных из них в VB6. Мы осуществляем проект по переводу приложений VB6 на .NET 3.5.

Все приложения c # 1.1 написаны с использованием традиционного n-уровневого подхода. На самом деле нет никакой архитектуры / разделения на уровне пользовательского интерфейса. Большая часть кода просто реагирует на события и отправляется оттуда. Я бы сказал, что с точки зрения ремонтопригодности, это было довольно хорошо, и легко следовать за кодом и быстро освоить новые приложения.

Поскольку мы портируем приложения VB6, изначально мы думали, что нам следует придерживаться существующего шаблона (например, n-уровня).

Мне интересно, стоит ли нарушать шаблон и делать приложения VB6, используя шаблон MVP / MVC? Действительно ли приложения winform MVC / MVP легче поддерживать? Я работал над проектом на основе MVC и не чувствовал, что его легче поддерживать, но это всего лишь один проект.

Какие у вас есть опыт и советы?

Answer 1

Чувак, если у тебя что-то работает, ребята, тебе это удобно, и твоя команда справляется с этим. Зачем тебе менять?

MVC / MVP звучит хорошо ... Тогда почему я до сих пор сам работаю над n-Tier?

Я думаю, прежде чем выделять ресурсы для фактической разработки этого нового способа программирования ... Вы должны подумать, работает ли он для ВАШЕЙ команды.

Answer 2

Если вы портируете приложения VB6 вместо полного переписывания, я бы посоветовал сосредоточиться на вашей цели Pri 1 - как можно быстрее попасть в мир .Net. Просто выполнение этого принесло бы много пользы вашей организации.

Когда вы окажетесь там, вы сможете оценить, выгодно ли вам инвестировать в реорганизацию этих приложений.

Если вы делаете полное переписывание, я бы сказал, что сделайте решительный шаг и перейдите к WPF-приложениям с шаблонами MVP / MVVM. WPF даст вам более приятные визуальные эффекты. Шаблон MVP / MVVM даст вам возможность тестировать модуль для всех слоев, включая визуальный. Я также предполагаю, что эти приложения связаны между собой, поэтому есть вероятность, что вы действительно сможете повторно использовать свои модели и представления. (хотя я могу ошибаться)

Answer 3

Он перемещает тонкий слой кода, который вы, вероятно, все еще имеете в пользовательском интерфейсе. Я говорю худой, потому что из вашего описания у вас, вероятно, есть много кода в другом месте. Это дает вам возможность модульного тестирования этого тонкого слоя кода.

Обновление 1: Я не рекомендую перепроектировать архитектуру при выполнении обновления, дополнительные усилия - это лучшие затраты на получение автоматических тестов (модуль / интеграция / система) - поскольку вам придется тестировать обновление работает в любом случае. После того, как у вас есть тесты, вы можете постепенно вносить изменения в приложение с удобством проведения тестов для поддержки изменений.

Answer 4

«Изменение - это деятельность, в которой мы участвуем, чтобы дать намек на прогресс». - Дилберт

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

MVC и MVVM являются отличными моделями, особенно с точки зрения тестируемости. Не забывайте о них, но, возможно, вам стоит рассмотреть пилотный проект до полномасштабного принятия?

Answer 5

В частности, MVC не исключает n-уровневую архитектуру.

У нас также есть бизнес-приложение ASP.NET 1.1, и я считаю его настоящим кошмаром. Когда обработчики событий делают все, что им нравится, возможно, настраивают другие элементы управления, могут вызывать что-то в бизнес-логике, могут напрямую общаться с базой данных, только случайно программное обеспечение работает вообще.

При правильном использовании MVC вы можете видеть, как данные передаются из базы данных в ваш пользовательский интерфейс и обратно. Это облегчает отслеживание ошибок, если вы получили неожиданное поведение.

По крайней мере, так было с моим собственным маленьким проектом.

Я еще раз подчеркну: какой бы шаблон вы ни использовали, придерживайтесь четкой n-уровневой архитектуры. 2-х или 3-х уровневые, только не путайте все в большой взаимосвязанный шар.