Entity Framework CTP5 и Ninject как мой IOC

Возможно ли в Entity Framework CTP5 создавать извлеченные сохраненные сущности через контейнер IOC?

Я использую Ninject, и он хорошо связан с MVC, но мне нужно внедрить некоторые службы в объекты моего домена, когда они созданы для некоторых бизнес-правил.

Я бы предпочел сделать это с помощью инъекции конструктора, чем инъекции метода или свойства.


person WDuffy    schedule 30.12.2010    source источник


Ответы (3)


Я не уверен, что именно вы пытаетесь здесь сделать, но EF почти не имеет точек расширения. Лучшее, что вы можете сделать, - это подключиться к событию ObjectMaterialized, запускаемому ObjectContext. В CTP5 вам нужно преобразовать свой DbContext в конструктор вашего DbContext следующим образом:

((IObjectContextAdapter)this).ObjectContext.ObjectMaterialized += 
    this.ObjectContext_OnObjectMaterialized;

А затем реализуйте свою функцию ObjectContext_OnObjectMaterialized(object sender, ObjectMaterializedEventArgs e). Вы сможете получить доступ к своему объекту, который, к сожалению, уже реализован. В зависимости от ваших потребностей, вы можете взломать здесь какое-нибудь интересное поведение.

Кстати, это предложение не имеет для меня смысла:

Мне нужно внедрить некоторые репозитории в объекты моего домена, когда они созданы для некоторых бизнес-правил.

Разве это не противоречит постоянству невежественных объектов домена?

person anon    schedule 19.01.2011
comment
слово "репозитории" должно было быть "сервисами" (я обновил свой оригинал). Например, объект домена может иметь несколько возможностей отправки электронной почты, поэтому я хотел бы внедрить службу электронной почты при создании. - person WDuffy; 19.01.2011
comment
@WDuffy - Имеет смысл. К сожалению, этот ответ (social.msdn .microsoft.com / Forums / en / adonetefx / thread /) на форумах MS подтверждает, что, поскольку EF требует конструктора с нулевым аргументом для материализации ваших POCO, вы не можете использовать классическую инъекцию конструктора. Единственный обходной путь будет включать: 1) сделать этот конструктор внутренним, а затем 2) заставить этот конструктор вызывать конструктор, который ИМЕЕТ аргументы, которые разрешаются вашим контейнером IoC. К сожалению, это загрязняет ваш POCO проблемами IoC. - person anon; 20.01.2011
comment
интерфейс ICustomerRepository игнорирует постоянство. Если вы прочитаете синюю книгу DDD, вы заметите, что Эрик Эванс делает это даже на нескольких подробных диаграммах последовательности. В этом суть репозиториев, если они действительно являются репозиториями, а не просто причудливыми объектами доступа к данным. Я лично использую интерфейсы репозитория в своих общих корнях, и это отлично работает. - person Joshua Ramirez; 26.07.2011

Я склонен делать обратное тому, что вы пытаетесь сделать. Я делаю объекты своей области как можно более невежественными (по сути, это мешки собственности). Когда вам нужно выполнить какое-то действие, например отправить электронное письмо, я бы использовал для этого службу и использовал метод в доменном объекте, над которым он должен выполнить действие. В этом случае вам просто нужно будет внедрить службы в различные части вашего приложения (что намного проще выполнить с помощью Ninject).

person Brian Ball    schedule 19.01.2011
comment
Несколько не по теме: мешки с недвижимостью настораживают. Это означает, что вы рискуете создать анемичный домен. Очень не по теме: Крутая аватарка =) - person anon; 20.01.2011
comment
Я вижу выгоду для обеих сторон (и в некоторой степени аргументировал это обеими сторонами). Я стараюсь сохранять простую проверку в объектах, поэтому в этом смысле я предполагаю, что они не являются строго пакетами свойств, но если объект достаточно сложен, размещение бизнес-логики быстро раздувает класс, и он может быстро превратиться в более 1000 строк. кода (я видел это много раз). Когда я думаю о словах «бизнес-логика», я склонен думать о сложной серии правил, в этом случае я предпочитаю отдельный класс, если это просто проверка, то размещение этого класса кажется разумным. Всегда любил Black Mage! - person Brian Ball; 20.01.2011
comment
+1. Я делаю то же самое; Я держу свои POCO почти без логики (за исключением очень простой проверки сеттера здесь и там). Такие проблемы, как отправка электронной почты, действительно относятся к уровню обслуживания. Внедрение сервисов в объекты домена кажется нелогичным, ИМО. - person Daniel Liuzzi; 17.02.2011
comment
Повторяю первый комментарий. Если ваши доменные объекты представляют собой пакеты свойств, то они больше похожи на доменные DTO, а не на доменные объекты. Анти-шаблон модели анемического домена Google. Кроме того, службы домена не предназначены для использования по умолчанию в логике вашего домена. Это противоречит цели объектов предметной области, инкапсулирующих бизнес-логику. - person Joshua Ramirez; 26.07.2011
comment
Вы можете использовать такие термины, как анемичная модель данных, и цитировать таких людей, как Фаулер и т. все скручено и трудно поддерживать. Истинная ценность любой системы в том, насколько хорошо она обслуживает своих пользователей, а не в том, что она следует различным принципам программирования. Я не противник принципов, но, насколько мне известно, сценарии реального мира всегда перевешивают теорию. - person Brian Ball; 26.07.2011
comment
Я понимаю прагматические настроения, Брайан, но тогда зачем заимствовать концепции (DDD) у людей, которых вы осуждаете, и использовать их не так, как задумано в наших проектах? Вы не можете съесть свой торт и съесть его. Либо запрограммируйте структурно разработанный процедурный код на вашем любимом объектно-ориентированном языке, либо воспользуйтесь принципами ООП, используя предметно-ориентированный дизайн, как задумал его основатель. Нет смысла смешивать парадигмы. Более того, ваше представление о ценности для бизнеса ограничивается только непосредственной пользой для пользователей, а не стратегической ценностью для бизнеса. Системы, которые избегают антипаттернов, устойчивы к будущему. - person Joshua Ramirez; 14.11.2011
comment
И чтобы повторить ваш анекдот о том, что системы более успешны без бизнес-логики внутри модели - я согласен с вашими наблюдениями. По моим наблюдениям, наша отрасль не совсем готова вкладывать доллары в переработку основной области. Слишком много разработчиков применяют DDD, не имея универсального языка, что полностью лишает смысла DDD. Программирование бизнес-логики в виде сценариев транзакций легко выполнять и читать, но нелегко поддерживать. Однако программировать бизнес-логику в дистиллированной модели сложно, легко читать и поддерживать. Компромиссы. ;) - person Joshua Ramirez; 14.11.2011

Я думаю, что первый код EF CTP 5 может помочь. Он поддерживает интерфейс IValidatableObject, который принимает объект ValidationContext в качестве аргумента. ValidationContext - это ServiceLocator, поэтому вы должны иметь возможность получить экземпляр контейнера IoC, используя объект validationContext. (Это только моя первоначальная мысль, хотя я ничего не пробовал). Извините, если мой английский не очень понятен.

Обновление. Извините, сразу после того, как я разместил этот комментарий, я понял, что вопрос совсем не такой, как я понял. Итак, я сам пробовал кое-что, и после нескольких попыток и многих других поисков в Google я смог кое-что найти. Я планировал опубликовать ответ здесь, но потом подумал против, так как ответ будет очень длинным. Итак, вместо этого я опубликовал этот блог.

http://nripendra-newa.blogspot.com/2011/02/entity-framework-ctp5-injecting-with.html

Может быть, это поможет некоторым гуглерам найти то же самое. Надеюсь, на этот раз я правильно понял вопрос.

person Nripendra    schedule 06.02.2011