Вы можете использовать flexbox здесь. Попробуйте это:
.wrap {
display: flex;
justify-content: space-between;
}
.logo {
overflow: hidden;
text-align: left;
position: relative;
height: 60px;
background-color: white;
color: #1F6C8B;
font-family: Arial;
}
LOGO
abcdefg
jsfiddle: https://jsfiddle.net/dm198kpx/2 /
Я наконец-то с этим разобрался. Это выглядит так:
IoC Uml http://img396.imageshack.us/img396/1343/iocuml.jpg
with сборки
Чтобы получить его с помощью StructureMap, мне потребовался специальный «ITypeScanner» для поддержки сканирования сборок:
public class MyScanner : ITypeScanner {
public void Process(Type type, PluginGraph graph) {
if(type.BaseType == null) return;
if(type.BaseType.Equals(typeof(PersonBase))) {
graph.Configure(x =>
x.ForRequestedType<PersonBase>()
.TheDefault.Is.OfConcreteType(type));
}
}
}
Поэтому мой основной код выглядит следующим образом:
ObjectFactory.Configure(x => x.Scan (
scan =>
{
scan.AssembliesFromPath(Environment.CurrentDirectory
/*, filter=>filter.You.Could.Filter.Here*/);
//scan.WithDefaultConventions(); //doesn't do it
scan.With<MyScanner>();
}
));
ObjectFactory.GetAllInstances<PersonBase>()
.ToList()
.ForEach(p =>
{ Console.WriteLine(p.FirstName); } );
Что мы делаем в моем текущем проекте (который использует AutoFac, а не StructureMap, но я думаю, что это не должно иметь значения):
У нас есть интерфейсы, определяющие внешние сервисы, которые приложение использует в сборке ядра, скажем, App.Core
(как и ваша PersonBase).
Затем у нас есть реализации этих интерфейсов в Services.Real
(как Bob.dll) ,
В нашем случае у нас также есть Service.Fake
, который используется для облегчения тестирования пользовательского интерфейса с зависимостями от других корпоративных сервисов и баз данных и т. Д.
Само клиентское приложение внешнего интерфейса ( в нашем случае приложение ASP.NET MVC) ссылается на App.Core
.
Когда приложение запускается, мы используем Assembly.Load
для загрузки соответствующей DLL-библиотеки реализации «Services», на основе параметра конфигурации.
Каждая из этих DLL имеет реализацию IServiceRegistry, которая возвращает список сервисов, которые она реализует:
public enum LifestyleType { Singleton, Transient, PerRequest}
public class ServiceInfo {
public Type InterfaceType {get;set;}
public Type ImplementationType {get;set;}
// this might or might not be useful for your app,
// depending on the types of services, etc.
public LifestyleType Lifestyle {get;set;}
}
public interface IServiceRegistry {
IEnumerable<ServiceInfo> GetServices();
}
... приложение находит этот ServiceRegistry через отражение и перечисляет через эти экземпляры ServiceInfo и регистрирует их на контейнере. Для нас этот регистр-все-сервисы живет в веб-приложении, но его можно (и во многих случаях желательно) разместить в отдельной сборке.
Таким образом, мы можем изолировать логику домена от кода инфраструктуры, и не допускать обходных путей «просто в этот раз», когда приложение заканчивается, в зависимости от прямой ссылки на код инфраструктуры. Мы также избегаем использования ссылки на контейнер в каждой реализации Служб.
Одна очень важная вещь, если вы делаете это: убедитесь, что у вас есть тесты, которые подтверждают, что вы можете создавать каждый тип «верхнего уровня» (в нашем случае ASP.NET MVC Controllers) с каждой потенциальной конфигурацией контейнера IOC.
В противном случае довольно легко забыть реализовать один интерфейс и разбить огромные части вашего приложения.
Вы также можете настроить XML с помощью StructureMap. Вы можете даже смешать их, если хотите.
Есть также Атрибуты StructureMap, которые вы можете поместить в свой класс Bob, чтобы сообщить StructureMap, как загрузить сборку. DefaultConstructor - это тот, который я использую время от времени.
Параметр автоматической проверки работает только в том случае, если соблюдаются соглашения об именах, сборках и пространствах имен. Вы можете вручную настроить структурную карту с помощью свободного интерфейса. Пример:
ObjectFactory.Initialize(initialization =>
initialization.ForRequestedType<PersonBase>()
.TheDefault.Is.OfConcreteType<Bob>());