AutoFac, автосоединяющий конвенции проводом
Исключения должны не использоваться в качестве метода передающей информации внутренне между методами в Вашем объекте, локально необходимо использовать коды ошибки и безопасное программирование.
Исключения разработаны для передачи управления от точки, где ошибка обнаруживается к месту (выше стек), где ошибка может быть обработана, по-видимому, потому что локальный код не имеет достаточного количества контекста для исправления проблемы и чего-то выше, что стек будет иметь больше контекста и таким образом будет в состоянии лучше организовать восстановление.
При рассмотрении исключений (в C++, по крайней мере) необходимо полагать, что исключение гарантирует, что API делает. Минимальный уровень гарантии должен быть Основной гарантией, хотя необходимо стремиться (где соответствующий) обеспечить сильную гарантию. В случаях, откуда Вы не используете внешних зависимостей суставного API, можно даже попытаться не обеспечить гарантию броска.
N.B. не путают гарантии исключения со спецификациями исключения.
Гарантии Исключения:
Никакая Гарантия:
нет никакой гарантии о состоянии объекта после того, как исключение выходит из метода В этих ситуациях, объект больше не должен использоваться.
Основная Гарантия:
почти Во всех ситуациях это должно быть гарантией минимума, которую что обеспечивает метод. Это гарантирует, что состояние объекта четко определено и может все еще последовательно использоваться.
Сильная Гарантия: (иначе Транзакционная Гарантия)
Это гарантирует, что метод будет полностью успешно, Или Исключение будет выдано, и состояние объектов не изменится.
Никакая Гарантия Броска:
метод гарантирует, что никаким исключениям не позволяют распространить из метода. Все деструкторы должны сделать эту гарантию.
| N.B. Если исключение выйдет из деструктора, в то время как исключение уже распространяет
|, то приложение завершится
2 ответа
Для версий Autofac из v2
Новые функции сканирования в Autofac2 imo устранят некоторые потребности в регистрации по соглашению. Допустим, Foo находится в Plugins.dll:
var assembly = Assembly.Load("Plugins");
builder.RegisterAssemblyTypes(assembly)
.AsImplementedInterfaces();
Эта регистрация подберет Foo и зарегистрирует его как IFoo .
Для версий Autofac меньше чем v2
Вы можете использовать ContainerBuilder.RegisterTypesMatching. Вот пример:
var builder = new ContainerBuilder();
builder.RegisterTypesMatching(type => type.IsAssignableFrom(typeof(IFoo)));
var container = builder.Build();
var foo = container.Resolve<Foo>();
Питер, он имеет в виду стандартное сканирование по соглашению, которое доступно в StructureMap. Он автоматически связывает IX и X, где X - это класс, реализующий интерфейс IX. Это работает следующим образом:
public override void Process(Type type, Registry registry)
{
if (!type.IsConcrete()) return;
Type pluginType = FindPluginType(type);
if (pluginType != null && Constructor.HasConstructors(type))
{
registry.AddType(pluginType, type);
ConfigureFamily(registry.For(pluginType));
}
}
public virtual Type FindPluginType(Type concreteType)
{
string interfaceName = "I" + concreteType.Name;
Type[] interfaces = concreteType.GetInterfaces();
return Array.Find(interfaces, t => t.Name == interfaceName);
}
Я также хотел бы знать, поддерживает ли Autofac подобное. StructureMap позволяет вам определять ваши собственные IRegistrationConvention. Это один из примеров соглашения.