Ninject по сравнению с единицей для [закрытого] DI
Хорошо, я сказал, что немного подробнее расскажу о своем мнении о «закрытых классах». Я предполагаю, что один из способов показать, какой ответ мне интересен, это дать его самому:)
Мнение: классы должны быть запечатаны по умолчанию в C #
Обоснование:
Нет сомнений в том, что наследование является мощным. Тем не менее, это должно быть несколько руководствоваться. Если кто-то наследует базовый класс совершенно неожиданным образом, это может нарушить предположения базовой реализации. Рассмотрим два метода в базовом классе, где один вызывает другой - если оба метода являются виртуальными, то эти детали реализации должны быть задокументированы, в противном случае кто-то может вполне разумно переопределить второй метод и ожидать, что вызов первого сработает. И, конечно, как только реализация документируется, ее нельзя изменить ... поэтому вы теряете гибкость.
C # сделал шаг в правильном направлении (относительно Java), сделав методы запечатанными по умолчанию. Тем не менее, я считаю, что еще один шаг - сделать классы запечатанными по умолчанию - был бы еще лучше. В частности, легко переопределить методы (или не явным образом запечатать существующие виртуальные методы, которые вы не переопределяете), так что в результате вы получите непредвиденное поведение. Это на самом деле не помешает вам делать все, что вы можете сделать в настоящее время - это просто изменение по умолчанию , а не изменение доступных параметров. Это было бы "более безопасным" по умолчанию, хотя, как и доступ по умолчанию в C #, всегда "самая частная видимость, доступная на тот момент".
Делая людей явно заявляющими, что они хотят чтобы люди могли учиться на своих уроках, мы призываем их подумать об этом немного больше. Это также помогло бы мне с моей проблемой лени - хотя я знаю, что я должен запечатывать почти все мои классы, я редко на самом деле не забываю это делать: (
Встречный аргумент :
Я вижу аргумент, который говорит о том, что класс, у которого нет виртуальных методов, может быть выведен из относительно безопасно без дополнительной гибкости и обычно требуемой документации. Я не уверен, как противостоять этому в настоящий момент, кроме того, чтобы сказать, что я считаю, что вред случайно вскрытых классов больше, чем вред случайно запечатанных.
3 ответа
В прошлый раз, когда я смотрел на любой из них, я обнаружил, что Ninject немного лучше. Но у обоих есть свои недостатки.
Ninject имеет лучшую схему плавной конфигурации. Похоже, что Unity в основном полагается на конфигурацию XML. Ninject ' Главный недостаток заключается в том, что для добавления атрибутов [Inject] требуется ссылаться на Ninject.Core повсюду в коде.
Если я могу спросить, почему вы ограничиваете свой выбор этими двумя? Я думаю, что Castle.Windsor, Autofac и StructureMap не хуже или лучше.
I agree with Mendelt, there is no "best" DI framework. It just depends on the situation and they all have pros and cons. think David Hayden said on DotNet Rocks that Unity is the preferred choice if you use the rest of EntLib and are familiar with that. I personally use Unity because my customer likes the fact that it says Microsoft Enterprise Library (Unity) on the DLLs, if you get what I´m saying.
I use both both xml configuration for setting up the interfaces and their concrete implementations but then I use attributes in code when injecting, like:
<type type="ILogger" mapTo="EntLibLogger">
<lifetime type="singleton"/>
</type>
and in code:
[InjectionConstructor]
public Repository([Dependency] ILogger logger)
Personally I think that makes it clearer what happens, but of course one could argue that you will have references to unity all over your application. It´s up to you.
Я знаю, что это старый вопрос, но вот мои мысли:
Мне лично нравится Ninject. Мне нравится плавный интерфейс и отказ от XML. Мне вообще нравится XML, но не для такого рода конфигов. Свободные интерфейсы облегчают исправление, особенно при рефакторинге.
Мне не хватает ObjectFactory StructureMap, но есть простые обходные пути, чтобы добавить это в Ninject.
Как указывает Джеффри, вам не нужно использовать атрибут [Inject], когда у вас есть только один конструктор.
Я обнаружил, что предпочитаю плавные интерфейсы не только потому, что они избегают XML, но и потому, что они вызывают ошибки времени компиляции, когда я меняю что-то, что на них влияет. Конфигурация XML этого не делает, и чем меньше мне нужно помнить , тем лучше мне становится.