String a = new String("foo");
String b = new String("foo");
System.out.println(a == b); // prints false
System.out.println(a.equals(b)); // prints true
Убедитесь, что вы понимаете, почему. Это потому, что сравнение ==
сравнивает только ссылки; equals()
метод сопоставляет содержимое по символу.
Когда вы вызываете new для a
и b
, каждый получает новую ссылку, указывающую на "foo"
в таблице строк. Ссылки разные, но контент один и тот же.
Я в основном согласен с ответом Криса, но я думаю, что файлы конфигурации неприятны (особенно для Unity), поэтому вот решение, которое позволит вам использовать конфигурацию времени выполнения без циклических ссылок. Мы собираемся сделать это с реестрами.
Создайте проект инфраструктуры, который будет содержать IConfigureUnity.
public interface IConfigureUnity
{
public void Configure(UnityContainer container);
}
Каждый из ваших проектов библиотеки классов будет отвечать за реализацию этого интерфейса для регистрации собственных классов.
public class RegistryForSomeClassLibrary : IConfigureUnity
{
public void Configure(UnityContainer container)
{
container
.RegisterType<IObjectContext, ObjectContextAdapter>()
.RegisterType<IConnectionStringProvider, ConnectionStringProvider>()
.RegisterType(typeof(IRepository<>), typeof(Repository<>));
}
}
Затем в своем проекте WPF вам нужно будет создать контейнер и применить эти реестры.
var container = new UnityContainer();
new RegistryForSomeClassLibrary().Configure(container);
new RegistryForAnotherClassLibrary().Configure(container);
Теперь у вас есть полностью настроенный экземпляр контейнера без каких-либо файлов конфигурации.
Чтобы несколько проектов использовали один и тот же UnityContainer в этом сценарии, вам нужен «общий» проект, который содержит ваш UnityContainer и предоставляет его таким образом, чтобы все другие проекты могли получить к нему доступ.
т.е.
Проект WPF
Библиотека классов 1
Библиотека классов 2
Библиотека классов 3
Общая библиотека (здесь находится UnityContainer)
Чтобы избежать циклических зависимостей проекта, я бы рекомендовал использовать Конфигурация Unity во время разработки через файл конфигурации вместо конфигурации во время выполнения (как в вашем примере). В противном случае ваша общая библиотека должна будет ссылаться на проекты, которые содержат все типы, которые она разрешает, и эти проекты, в свою очередь, будут зависеть от общей библиотеки (поскольку это, предположительно, то место, где вы бы открывали экземпляр UnityContainer). Возможно, вы сможете заставить его работать, используя конфигурацию времени выполнения, но я этого не пробовал; Я знаю, что конфигурация во время разработки работает, поскольку я выполнил несколько проектов с использованием именно такой модели.