IoC и события - PullRequest
Новая
       24

IoC и события

2 голосов
/ 05 февраля 2009

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

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

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

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

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

1 Ответ

4 голосов
/ 05 февраля 2009

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

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

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

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

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

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

...