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