Инициализация AutoMapper

Здравствуйте. Создаю ASP.NET MVC проект, с трехслойной архитектурой (DataAccess, BusinessLogic, PresentationLayer). В BusinessLogic есть DTO сущности для передачи данных из DAL в PresentationLayer, в котором, в свою очередь есть ViewModel'и для передачи данных в представления. Для маппинга данных из одних сущностей на другие использую AutoMapper v6.2.2. В PresentationLayer, в Global.asax (в Application_Start()) вызываю
для маппинга сущностей BLL и PresentationLayer;
Вопрос: где производить CreateMap<> для сущностей DAL и BLL? Если еще раз вызвать Mapper.Initialize(cfg => ..... в слое BLL, То будет исключение :

Mapper already initialized. You must call Initialize once per application domain/process.

В Global.asax (в Application_Start()) в слое PresentationLayer я не могу вызвать cfg.CreateMap<SomeDALEntity, Some_DTO>(), поскольку в PresentationLayer придется дабавлять ссылку на DAL, что делает бессмысленным многослойную архитектуру приложения. Заранее спасибо.

0

Сообщение от plusok где производить

В DAL и производите. Каждый объект репозитория создает маппинг на свой сырой объект из Dal. (Из Data Model, то бишь на сущность из базы).

Сообщение от plusok в котором, в свою очередь есть ViewModel'и

ViewModel-и должны быть частью BLL, поскольку это тоже модели. Просто модели для представлений. По-хорошему вы можете просто подменять ваш Presentation Logic Layer (winforms, wpf, консольку), скармливая вьюхам
одни и те же вью модели из BLL. Поскольку вью-модели не зависят от вьюх.

0

Каждый слой ничего не знает о вышележащих слоях , значит , если слою BLL нужен Mapper для DAL модели . он вправе его использовать , так же как и PresentationLayer не обязан понимать что творится внутри BLL , т.е так же вправе вызвать Mapper моделей BLL на свои модели представления. Но , раз уж Mapper такой себе singleton , наверняка есть возможность проверить была ли инициализация и сбросить ее.

Добавлено через 2 минуты

Сообщение от IamRain ViewModel-и должны быть частью BLL, поскольку это тоже модели.

позволю себе не согласиться , BLL и логика интерфейса - разные вещи , кроме того BLL может использоваться в сервисах где вообще интерфейсом и не пахнет , т.е никаких ViewModel там быть не должно.

0

Сообщение от sau BLL и логика интерфейса - разные вещи

Я понимаю, что разные. Но логика интерфейса - это движущая сила для любого приложения, то есть она определяет все основные workflow в приложении.
Если стоит задача сменить графическую платформу, при этом все воркфлоу остаются теми же самыми (например, при переходе от десктопа на веб), то получается надо заново писать вьюмодели для веба? - Логично, что не надо этого делать. Ведь вьюмодели не должны зависеть от вьюх, поэтому пихаем вьюмодели в BLL. Повторюсь, это ведь тоже модели.

Добавлено через 1 минуту

Сообщение от sau т.е никаких ViewModel там быть не должно.

В сервисах мы их и не будем попросту использовать. Хотя момент сервисами мне не совсем понятен.

0

IamRain, спасибо вам за участие, но я бы рекомендовал вам почитать что-то на тему SOLID принципов, или вот это https://metanit.com/sharp/mvc5/23.5.php.
sau - по поводу "сбросить инициализацию" - да такая возможность есть, но в доках сказано что методом Reset() не рекомендуется пользоваться "на проде":

Resets the mapper configuration. Not intended for production use, but for testing scenarios.

Та и потом, если например, где-нибудь в BLL его скинуть, то потом в PresentationLayer опять нужно будет инициализировать, а с Global.asax так не получится; а пихать инициализатор еще куда-нибудь в слое PresentationLayer, с , опять-таки проверкой на то, был ли маппер инициализирован ранее - это уже избыток...
Просто не хочется изобретать колесо.... Думаю уже кто-то с подобным сталкивался, хочется какое-то "правильное"решение.

0

plusok, насколько я помню в рабочем проекте мы именно в DAL и иницализируем маппинг, причем сразу для всех сущностей из BLL, через рефлексию. + Используется свой convention по именованию сущностей.
Получается, есть базовый класс репозитория, который иницализирует маппинг, а все остальный репозитории от него наследуются.
В любом репозитории маппинг уже на блюдечке, типа того. Вот и все.

0

Сообщение от IamRain В сервисах мы их и не будем попросту использовать. Хотя момент сервисами мне не совсем понятен.

Бизнес логика обрабатывает какой либо бизнес процесс (или множество ) . например в документообороте этапы рассмотрения , согласования , утверждения документа и т.п.
Естественно , что для каждого этапа безнеспроцесса могут быть разные виды обслуживающих его приложений , со своим пользовательским интерфейсом , или без него - в случае каких либо фоновых процессов/сетевых сервисов , решающих свой круг задач в рамках общего бизнеспроцесса. , но при этом все они взаимодействуют через общую бизнес логику.
По этому и вью.моделей будет множество для разных UI , если есть общая вью.модель она может быть вынесена в доменную для UI , а BLL тем временем живет своей жизнью и ей совершенно по барабану какие у нее клиенты в виде тех или иных приложений уровня пользователя. Короче , UI модель обслуживает конкретный тип интерфейса. и должна располагаться в ближайшим к нему слое. (архитектуру UI так же можно подразделить на несколько локальных слоев , тот же MVP обеспечит общий подход в логике UI как для веба так и для десктопа , но это не значит что этот слой нужно помещать в BLL)

Добавлено через 6 минут

Но логика интерфейса - это движущая сила для любого приложения, то есть она определяет все основные workflow в приложении.

Нет , она лишь является точкой взаимодействия пользователя с тем или иным workflow , но никак не определяет его правила работы. Наоборот , интерфейс подчиняется правилам worklow , и более того , может лишь частично представлять доступ к его более широкому функционалу , в рамках своего предназначения.


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

0

Сообщение от sau Короче , UI модель обслуживает конкретный тип интерфейса.

sau, ну почему же, не пойму я никак? Я проецирую DAL, BLL, Presentation Logic Layer на MVVM.
Зачем для каждой View писать View Model? View Model не зависит от View-хи, на то она и ViewModel.
Допустим, спроектировали наше большое приложение. Сформировали основные use case-ы, в одном из use case-ов определили activity - редактирование данных пользователя (DetailView).
Модели ведь не должны зависеть от вьюх, в этом вы согласны со мной? Так кот зачем при смене UI например с WinForms на ASP MVC переписывать ViewModel? На крайняк, разве что повесить на ViewModel дополнительно описывающие метаданные с помощью атрибутов (одна строка кода во вью-модели - единственное изменение) и все, ничего более.

Добавлено через 5 минут

Сообщение от sau Нет , она лишь является точкой взаимодействия пользователя с тем или иным workflow , но никак не определяет его правила работы

Понятно, что не определяет, но по-хорошему, однажды написанной логики интерфейса (читай ViewModel-и) согласно указанному workflow, будет достаточно, ведь логика взаимодействия определилась? - Да, и она не собирается меняться, она осталась такой же. Соответственно, менять нужно только вьюхи, через которые пользователь взаимодействует с системой.
Вообщем, ключевая фраза - логика взаимодействия пользователя с view не меняется, поэтому не меняется ViewModel, меняется только View.

0

Сообщение от plusok Та и потом, если например, где-нибудь в BLL его скинуть, то потом в PresentationLayer опять нужно будет инициализировать, а с Global.asax так не получится; а пихать инициализатор еще куда-нибудь в слое PresentationLayer, с , опять-таки проверкой на то, был ли маппер инициализирован ранее - это уже избыток...

Тогда это хренатень не походит , какой вообще смысл делать singleton маппер , когда очевидно это может понадобиться в различных независимых друг от друга местах , а если Вы подключите сборку в проект где этот же самый мапер , все , кранты и сборку не поюзать ? , фигня какая то.

Добавлено через 5 минут

Сообщение от IamRain Зачем для каждой View писать View Model? View Model не зависит от View-хи, на то она и ViewModel.

Вьюмодель не зависит от ее структуры представления в интерфейсе , Вы правы , интерфейс можно и так и эдак рисовать с применением одной модели , но вью.модель в этом случае определяет тип данных интерфейса , а если появляется интерфейс которому эта ViewModel не подходит , у него будет уже другая-своя вью.модель , но при этом оба этих интерфейса обслуживают общий workflow , и в этом случае будем пихать в workflow все возможные виды вью.моделей , которые еще и будут добавляться по мере появления дополнительных вариантов интерфейсов.
Мы же не говорим о монолитном и раз написанном приложении , разделение на слои подразумевает повторное использование в различных местах , где Presentation layer в какой то степени может быть повторно использован , но гораздо в меньшей степени чем BLL или DAL.

Я , например , разработчик api веб.сервиса для BLL , и тут мне в сборке суют какие то ViewModel_и специфичных UI , нахрена они мне в моем rest api сервисе, спрошу я ?

Сообщение от IamRain ведь логика взаимодействия определилась?

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

0

Сообщение от sau а если интерфейс не содержит логин-пароль , у него будет уже другая вью.модель

Логика взаимодействия с пользователем изменилась, так что это уже другая история Ну да ладно, не хочу спорить.

0

Сообщение от sau Тогда это хренатень не походит , какой вообще смысл делать singleton маппер , когда очевидно это может понадобиться в различных независимых друг от друга местах , а если Вы подключите сборку в проект где этот же самый мапер , все , кранты и сборку не поюзать ? , фигня какая то.

Я уже тоже к этому склоняюсь. )) В более ранних версия AutoMapper такого не было (Mapper already initialized. You must call Initialize once per application domain/process.) Наверное нужно глубже погрузится в доку, по любому есть какое-то решение

0

Что мешает в Dao/Bll определить класс, выполняющий исключительно инициализацию всех моделе своего уровня с Core интерфейсом, и на входной точке приложения собирать все реализации и вызывать?

0

PresentationLayer ничего не должен знать о DAL

0

Сообщение от plusok PresentationLayer ничего не должен знать о DAL

не факт. Onion-архитектура как пример.

0

Сообщение от plusok PresentationLayer ничего не должен знать о DAL

Если он не будет о нем знать, то и не сможет с ним работать. Как минимум об интерфейсе

вообще идея такая

- MyApp.Core
- MyApp.IDao
- MyApp.Dao
- MyApp.Bll
и где-то в недрах страрта апликейшена

0

plusok, не знаю зачем вам понабился DTO. При внедрении зависимости проект получает все зависимости проекта от которого он зависит. Т.е. если у вас BLL зависит от DAL, а UI зависит от BLL, UI получит все зависимости BLL и объекты DAL будут доступны на уровне UI. Это ж лишняя работа, лишний репозиторий.
Но если уж надо именно так, то схема следующая. Automapper инициализируется действительно один раз, в StartUp. Пакет его устанавливается в BLL и он будет доступен из UI. В UI устанавливается пакет

AutoMapper.Extensions.Microsoft.Dependen cyInjection

И в StartUp

Ну уровнях UI и BLL будет по репозиторию, один возвращает DTO, второй ViewModel. Оба через конструктор получают IMapper. На обоих уровнях прописывается по классу

Automapper подхватит профайлы и все отмаппит.

В StartUp прописываете оба репозитория и указываете, что в конструктор обоим следует передать IMapper, который получаете из сервисов.
Ну и все.

1

escoult, спасибо. Вот это похоже.... позже попробую - отпишусь.

Добавлено через 12 минут
Так же , как вариан попробовать инициализацию маппера не статически, а через экземпляры класса MapperConfiguration :

0

plusok, поправлю сам себя

Сообщение от escoult ... и указываете, что в конструктор обоим следует передать IMapper, который получаете из сервисов

Этого не нужно явно указывать. IMapper то уже зарегистрирован. Достаточно только зарегистрировать репозитории. Я что то сразу не подумал об этом.

0

Спасибо

0