2009-02-05 6 views
2

Мне очень сложно согласовать IoC, интерфейсы и события. Посмотрим, смогу ли я объяснить это, не написав книгу.IoC и события

Я только начинаю с IoC, и я играю с весной. У нас есть простой слой данных, который был построен задолго до EF или других. Один из классов - это DBProcedure, который имеет некоторые методы и события.

Я создал интерфейс IDBProcedure, который реализует «настоящий» класс DBProcedure. В режиме TDD я хотел бы иметь возможность поменять «настоящий» класс DBProcedure на другой, который реализует один и тот же интерфейс для тестирования. Для меня это означает, что интерфейс IDBProcedure должен быть в другом пространстве имен/проекте, чем мой уровень данных, верно?

Но DBProcedure может поднять некоторые события, и эти события доставляют пользовательские классы EventArgs. Означает ли это, что классы EventArgs необходимо определять вне слоя данных? Похоже на то, чтобы интерфейс работал, но это кажется плохим, потому что он распространяет неформальность данных вокруг?

С другой стороны, возможно, у меня есть неправильная идея - нормально ли включать пространство имен уровня данных, когда я тестирую, чтобы получить интерфейс и определения событий, даже если я не использую какие-либо из «реальных» классов?

ответ

4

Да, вам нужно переместить интерфейсы и все типы, от которых оно зависит, потому что вы не должны , чтобы модуль интерфейсов зависел от реализаций.

Типичный выбор для этого является один из двух вариантов

Impl ----> Api <---- client 

(реализация зависит от API, клиент, зависит от API, все в модуле апи)

Impl ----> Api <----- client 
\   |  /
\   V  /
    ------->Model<------ 

Здесь все зависит от общий «модельный» модуль, и это содержит перечисления и т. д. Преимущество этой версии состоит в том, что вы можете иметь несколько модулей API, имеющих общие общие перечисления и другие артефакты. (Потому что вы действительно не хотите, чтобы API зависел от других модулей API обычно)

+0

Это EXCTLY то, что мне нужно было знать - огромное спасибо! – n8wrl

+0

+1 - очень приятно. Очень хорошее отображение зависимостей пакетов с использованием ограниченной отображаемой палитры. – duffymo

+0

Я думал о добавлении второго пакета api к рисунку 2, но не был уверен, что смогу его снять;) – krosenvold