MVC - просмотр, который нуждается в нескольких моделях

Question

У меня проблема на концептуальном уровне, я много читаю, но меня еще нет. Я хотел бы смоделировать систему, которая планирует размещать заказы и позволяет выбирать товары в соответствии с выбранным местоположением. На этапе анализа правильно, что пользовательский интерфейс запрашивает данные для классов товаров, местоположения и заказов? На этапе проектирования, можете ли вы просматривать доступ к нескольким моделям и отображать данные, или это более правильно, если orderView имеет доступ только к модели заказа, и это берет все данные из базы данных (используя разные DAO для местоположения, заказа и продукта)? Заранее спасибо, Винченцо

Answer 1

Подход к решению этой проблемы заключается в использовании ViewModel (http://geekswithblogs.net/michelotti/archive/2009/10/25/asp.net-mvc-view-model-patterns.aspx), в основном составная модель, которая группирует несколько других моделей вместе, чтобы их можно было обслуживать для представления.

Таким образом, если у вас есть модель продукта, модель местоположения и модель заказа, все логически различные модели, которые вы хотите объединить вместе в одном представлении (например, сводка продаж за месяц), вы можете создать SalesSummaryViewModel, который содержит продукты, заказы и местоположения, которые должны быть возвращены в это представление.

Answer 2

Вы должны рассмотреть Модель View ViewModel , иметь ViewModel objects, созданную для обслуживания ваших потребностей представления, составляющих ваш бизнес-объект.

Answer 3

Абсолютов не существует

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

Отделение пользовательского интерфейса от данных от управления их взаимодействием является хорошей целью проектирования

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

Ради аргументов, давайте просто назовем основную идею MVC.MVP является вариацией этого, а MVVM (ViewModel) является специализацией нашего MVP.

MVVM / ViewModel является специфичной для .NET

Модель Model-View-ViewModel быласозданный архитекторами Microsoft для использования преимуществ WCF, XAML и Silverlight (в сравнении с ASP.NET и Windows Forms).В конечном счете, это вариант нашей базовой концепции, вариант, который, безусловно, использует технологии .NET.

Предоставление модели для просмотра
.. или нет, это суждение сужденияо том, сколько связи вы хотите между компонентами контроллера вида модели.

MVC дает вашему виду ссылку на вашу модель.Это удобно для привязки данных.Если вы используете архитектуру .NET Binding, вы можете использовать этот шаблон.

MVP - только Presenter (контроллер с большей мощностью, если хотите) видит данныемодель.Например, вы все еще можете использовать архитектуру .NET Binding, но докладчик - посредник, который все это подцепил.Зачем?Потому что вы приняли это обоснованное решение, основываясь на своем общем дизайне.

MVP означает, что докладчик хорошо знает представление и модель, поэтому он может связывать их вместе и обрабатывать входы пользовательского интерфейса.Отсюда следует, что для каждого представления есть Presenter, так как они являются настроенными парами, (скорее всего) не взаимозаменяемыми.

Инструменты разработки могут влиять на архитектуру проектирования

Напримересли вы разрабатываете в .NET WCF, у вас нет другого выбора, кроме как использовать MVVM;это то, как работает эта структура.

Аналогично, среда разработки для Mac OS X вынуждает вас использовать MVC.Так же как и Ruby On Rails и веб-разработка .NET MVC

Если вы используете какой-либо объект реляционного сопоставления объектов (ORM) - а .NET LINQ - один, то ваш дизайн может не иметь уровня доступа к данным как такового,

Answer 4

Если вам нужен пример, это делается в музыкальном магазине http://mvcmusicstore.codeplex.com/releases/view/64379#DownloadId=228002.

Подробности приведены на стр. 95 соответствующего PDF-файла.