Возможно ли повторно использовать WPF ViewModels в MVC? - PullRequest
4 голосов
/ 24 апреля 2011

у нас полнофункциональное клиентское приложение, написанное на WPF / WCF, и мы намерены создать сопутствующий веб-сайт на ASP.net (с использованием MVC, если это возможно).

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

Мыбудет повторно использовать нашу модель предметной области, но есть ли смысл отделять специфичные для WPF части наших моделей представления и повторно использовать независимые от WPF части в MVC?Это даже следует за теми же парадигмами?Мы используем RelayCommands исключительно для командования, поэтому было бы легко обернуть содержащиеся методы в нечто, специфичное для ASP.net ... Но как насчет вещей, специфичных для пользовательского интерфейса - например, ASP.net использует INotifyPropertyChanged - или как он обрабатывает обновления пользовательского интерфейса?

Ответы [ 2 ]

3 голосов
/ 24 апреля 2011

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

MVC не использует какой-либо механизм привязки для обновлений пользовательского интерфейса, поскольку веб-приложения по своей природе не имеют состояния.В действительности вы, скорее всего, в конечном итоге будете использовать модели представлений для своего приложения MVC, но в MVC они действуют как простые объекты передачи данных (DTO) для предоставления данных представлениям для рендеринга для каждого HTTP-запроса.После визуализации представления вам необходимо вернуться на сервер, чтобы обновить модель представления и повторно отобразить представление.

Кроме того, вы можете, конечно, обновить клиентскую часть пользовательского интерфейса с помощью сценариев. Knockout.js - хорошая библиотека JS для привязки модели / вида на стороне клиента.

2 голосов
/ 24 апреля 2011

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

С одной стороны,Логика, заключающаяся в том, что модель представления содержит очень мало кода, специфичного для вида, является дразнящим аргументом для повторного использования.С другой стороны, модель представления очень четко отвечает потребностям представления, и ожидать, что она будет обслуживать потребности другого представления, может быть проблематично.

В конце концов, все, что мы можем дать, - это рекомендации.Вы, конечно, не хотите монолитную модель представления с ifdefs или ifs повсюду.Вы могли бы преобразовать общие функциональные возможности в базовые классы - это объектно-ориентированный способ - но без хороших модульных тестов это наверняка сломает что-то в вашем уже работающем коде.Но не делать это означает иметь неприятный код вырезания и вставки, который почти одинаков и может расходиться, создавая кошмар обслуживания.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...