Мой ответ основан на Silverlight, и я понимаю, что он немного вырван из контекста, потому что вы спрашиваете с точки зрения MVC. Но, пожалуйста, позвольте мне проиллюстрировать, куда я положил свой EDMX.
Первое проектное решение
-Виджеты. Это несколько проектов пользовательского интерфейса с несколькими страницами XAML.
-Логика пользовательского интерфейса требует тщательной организации каждого виджета и страниц XAML в одном основном пользовательском интерфейсе.
-Просмотр-Модели. Они почти эквивалентны контроллерам в MVC. Я использую XAML для прямой привязки к моделям представления. Пример QuotationItemModel.vb и xyz.vb и тому подобное. Несколько страниц XAML могут совместно использовать одну виртуальную машину.
-XAML-страницы предполагают использование привязок команд в соответствии с реализацией View-Models. Пример нажатия кнопки направляется на виртуальную машину. Я не добился этого, потому что логика координации пользовательского интерфейса (от другого архитектора пользовательского интерфейса) мешала моему подключению к команде делегирования (CanExecute, Execute Func (Of Object, Boolean) Action (Of Object), вызывая переполнение стека в виджетах первого уровня. событие щелчка.)
-Модель. Здесь есть только одна функция. Ее задание подключает делегата к событию завершения асинхронного вызова веб-службы, а затем запускает веб-службу. Реализация Deletegate фактически находится в View-Model, то есть в QuotationItemModel.vb, а не внутри модели. В Model.vb действительно есть только одна функция.
-Другой логики в Модели нет. то есть Model.vb определяет конечные точки, привязки http, материалы WCF
- В этом решении нет EDMX. Модель также ничего не знает о базе данных.
Второй проект (но внутри третьего решения)
Реализация WCF. Легкий вес. Опять 1 функция. Только операционные контракты.
Код позади только передает бизнес-объекты в третий проект.
Строка подключения для EDMX настраивается здесь и передается третьему проекту.
Никакой другой логики.
О EDMX вообще ничего не известно.
Решение третьего проекта
-Начинается с простой фабрики для делегирования логики и вызова классов
-Начинается с простой заводской логики, становится очень тяжелым бэкендом. Использует шаблоны проектирования для облегчения проблем с обслуживанием. Отсюда шаблоны могут пересекаться между командами, стратегией или абстрактными типами и т. д. и т. д.
-Дизайн EDMX полностью проявляется в этом слое.
-Бизнес-объекты логически взаимодействуют с EDMX
-Я либо делаю LINQ to Entities, либо параметризованные запросы здесь
- Этот уровень состоит из бизнес-логики, такой как идентификатор андеррайтинга, который должен существовать до того, как транзакция требования может быть выдана. Или порядковый номер котировки, основанный на дате сервера. и т. д. и т. д.
-Есть некоторое ручное сопоставление бизнес-объектов с сущностями. Потенциально утомительно, но не всегда
-Результат передается обратно в виде XML
Третий проект вполне может быть отдельным решением с еще одним легким веб-сервисом между ними, что обеспечит готовность к трехуровневой архитектуре. Затем я создам свою собственную строку подключения к EDMX на этом чистом уровне. Но моя теперь больше похожа на архитектуру второго уровня «2.5». Я застенчиво выставляю строку подключения в веб-конфигурации среднего уровня. Архитектура означает наличие другой аппаратной платформы. Уровень — это разделение для предметно-ориентированного дизайна в проблемной области, т. е. пользовательского интерфейса, коммуникации и бизнес-областей. С технической точки зрения база данных SQL Server (помимо EDMX) вполне может находиться в другой архитектуре, например в Windows Azure.
Здесь я вижу плюсы и минусы. Пожалуйста, вносите любую критику осторожно, я действительно новичок в многослойности.
Минусы Без раскрытия контрактов данных мой пользовательский интерфейс слеп при общении на языке бизнес-объектов и контрактов. Раньше этого легко было добиться, имея EDMX на уровне WCF. Теперь я использовал Xelement для представления общего бизнес-объекта. Но мне все еще нужно найти способ раскрыть контракт данных, не раскрывая внутренности базы данных. В настоящее время я «инстинктивно» знаю и кодирую поля базы данных в своих Xelements.
Потенциально это похоже на тихую привязку к серверной части EDMX. Молчание иногда плохо, потому что, если я получаю столбец без данных, есть много предполагаемых причин. Ничего, что нельзя было бы решить с помощью хороших сообщений об ошибках из возвращенного результата XML. Используя свое воображение.
Слабый механизм управления версиями. Возможно, новые клиенты взаимодействуют с отдельным операционным контрактом для автоматического перенаправления на Backend-Ver 2.0, в то время как существующие клиенты используют Backend-Ver 1.0. Это потенциально означает, что теперь у вас должно быть 2 EDMX для каждой старой и новой базы данных соответственно.
Плюсы Экстремальная развязка. Я могу удалить/перестроить EDMX и пользовательский интерфейс, а WCF все еще компилируется. Только мое третье решение получит ошибку компиляции в этом экстремальном тестировании.
Из пользовательского интерфейса Silverlight запуск и связь с отчетом Microsoft Report Viewer использует точно такие же классы, которые вызываются из пользовательского интерфейса. Нет никаких «дополнительных функций веб-сервиса для отчета». Независимо от того, какая логика EDMX + запрашивается пользовательским интерфейсом, она точно такая же для отчета, если только я не выбрал ее. PS: Silverlight передает критерии фильтрации в отчет через строку запроса.
Отчет снова не знает о EDMX. Например, если я удаляю EDMX из серверной части, а затем обновляю подключение к данным из проекта отчета, проект отчета по-прежнему компилируется без проблем.
Готовность к миграции на множественную архитектуру без слез. Сезонная балансировка нагрузки, увеличение клиентской базы и т. д. могут вызвать эти инвестиции в архитектуру.
Повторное использование бизнес-логики. Например, если босс устанет от Silverlight, мне нужно будет просто перекодировать бизнес-объекты пользовательского интерфейса, скажем, в JSON?? под HTML 5. В бизнес-логике нет никаких изменений, кроме новых требований. Например, чтобы расширить страхование жизни для сосуществования с существующим общим страхованием, модуль, который в настоящее время закодирован в Silverlight. Представьте страхование жизни в HTML 5 и все еще сосуществующее с одним и тем же бэкэндом. Опять же, причина в том, что оба интерфейса не знают о EDMX, мне просто нужно сосредоточиться на построении контракта данных с помощью новой технологии.
Неожиданный (я действительно новичок в многослойности!) Побочный эффект. Я потенциально могу протестировать свой бэкенд отдельно от пользовательского интерфейса. Которые, в свою очередь, манипулируют LINQ to Entity (этим EDMX). Круто для модульного тестирования.
Обновление бизнес-логики не влияет на новое развертывание в IIS (средний уровень), за исключением случаев, когда речь идет об управлении версиями.
В любом случае, вот руководство по решению многоуровневых приложений от талантливого архитектора программного обеспечения Серены Йео.
Пример многоуровневой архитектуры для .NET
http://layersample.codeplex.com/
http://layerguidance.codeplex.com/
Обратите внимание на образец, который вы загружаете, изобретательность использования нескольких пользовательских интерфейсов для разных технологий на общем бэкэнде, где EDMX живет и спит. И более того, поверх основы рабочего процесса Windows, выборочно вызываемой по мере необходимости. Вы можете видеть, куда Серена поместила EDMX, и у вас есть рабочий код. Блаженство.
person
Fun Chiat Chan
schedule
16.03.2012
