Возможно ли в Entity Framework CTP5 построить извлеченные объекты с сохранением через контейнер IOC?Entity Framework CTP5 и Ninject as my IOC
Я использую Ninject, и он связан с MVC, но мне нужно добавить некоторые объекты в объекты моего домена, когда они созданы для некоторых бизнес-правил.
Я предпочел бы это сделать, используя инъекцию конструктора, чем инъекции метода или свойства.
Я не уверен, что именно вы пытаетесь выполнить здесь, но EF почти не имеет точек экстенсивности. Лучшее, что вы можете сделать, это подключиться к событию ObjectMaterialized, запущенному ObjectContext. В CTP5, вы должны бросить свои DbContext как и в конструкторе для DbContext:
((IObjectContextAdapter)this).ObjectContext.ObjectMaterialized +=
this.ObjectContext_OnObjectMaterialized;
А затем реализовать функцию ObjectContext_OnObjectMaterialized(object sender, ObjectMaterializedEventArgs e). Вы сможете получить доступ к своему объекту, который, к сожалению, уже реализован. В зависимости от ваших потребностей вы можете взломать здесь какое-то интересное поведение.
Кстати, это предложение не имеет смысла для меня:
мне нужно вводить несколько репозиториев в мои доменных объекты, когда они построены для некоторых бизнес-правил.
Разве это не противоречит Перенесение объектов Невежественного домена?
Я стараюсь сделать обратное тому, что вы пытаетесь сделать. Я делаю свои объекты домена настолько невежественными, насколько это возможно (они, по сути, являются мешками собственности). Когда вам нужно выполнить какое-то действие, например отправить электронное письмо, я бы воспользовался службой для этого и применил метод к объекту домена, которому он должен выполнить действие. В этом случае вам просто нужно будет внедрять службы в различные части вашего приложения (что намного проще выполнить с помощью Ninject).
Немного не по теме: «мешки с недвижимостью» вызывает тревогу. Это означает, что вам угрожает создание анемичного домена. Очень не по теме: Cool avatar =) – anon
Я вижу преимущества для обеих сторон (и в какой-то степени аргументировал обе стороны). Я, как правило, придерживаюсь простой проверки в объектах, поэтому в этом смысле я предполагаю, что они не являются сугубо мерами собственности, но если объект достаточно сложный, то бизнес-логика быстро раздувает класс, и он может быстро стать более 1000 строк кода (я видел, что это случается много). Когда я думаю о словах «бизнес-логика», я склонен думать о сложной серии правил, если это так, я предпочитаю отдельный класс, если это просто проверка, а затем помещение в класс кажется разумным. Всегда любил Черный Маг! –
+1. Я делаю то же самое; Я сохраняю свои POCOs практически без логики (за исключением очень простой проверки сеттера здесь и там.) Проблемы, такие как отправка электронной почты, действительно относятся к уровню обслуживания. Инъекционные услуги в доменных объектах кажутся противоречивыми, ИМО. –
Я думаю, что код EF сначала CTP 5 может помочь. Он отличает интерфейс IValidatableObject, который принимает объект ValidationContext в качестве аргумента. ValidationContext - это ServiceLocator, поэтому вы можете получить экземпляр контейнера IoC с помощью объекта validationContext. (Это только моя первоначальная мысль, я ничего не пробовал). Извините, если мой английский не очень понятен.
Обновление Извините, сразу после того, как я разместил этот комментарий, я понял, что вопрос совсем другой, чем я понял. Итак, я попробовал немного вещей сам, и после некоторых хитов и испытаний и гораздо больше googling я смог где-то добраться. Я собирался опубликовать здесь ответ, но потом подумал об этом, так как ответ был бы очень долгим. Итак, я опубликовал этот блог.
http://nripendra-newa.blogspot.com/2011/02/entity-framework-ctp5-injecting-with.html
Может быть, это может помочь некоторым сотрудникам Google, которые ищут то же самое. Надеюсь, на этот раз у меня вопрос.
слова репозитории должны были быть сервисами (я обновил оригинал). Например, объект домена может иметь несколько возможностей отправки электронной почты, поэтому я хотел бы добавить службу электронной почты при строительстве. – WDuffy
@WDuffy - имеет смысл. К сожалению, этот ответ (http://social.msdn.microsoft.com/Forums/en/adonetefx/thread/c33019e9-2ac4-4cc6-9e0b-3c6557fbf0a6) на форумах MS подтверждает, что, поскольку EF требует конструктора с нулевым аргументом, материализуйте свои POCOs, вы не можете использовать классическую инъекцию конструктора.Единственным обходным решением было бы: 1) сделать этот конструктор внутренним, а затем 2) заставить этот конструктор вызвать конструктор, который содержит аргументы HAS, которые разрешены вашим контейнером IoC. Это, к сожалению, загрязняет ваш POCO проблемами IoC. – anon
Интерфейс ICustomerRepository является ненасытным. Если вы прочтете синюю книгу DDD, вы заметите, что Эрик Эванс даже сделал это в нескольких подробных диаграммах последовательности. Это точка репозиториев, если они действительно являются репозиториями, а не просто причудливыми объектами доступа к данным. Я лично использую интерфейсы репозитория в своих собственных корнях, и он отлично работает. –