Ожидание возможной ситуации с круговой ссылкой в ​​предстоящей идее проекта .Net, что бы вы ни заботили?

Question

Итак, у меня есть этот уровень доступа к данным, и я также хочу войти в базу данных. В духе еды собственной собачьей еды я хочу использовать свой уровень доступа к данным для ведения журнала. Однако я также хочу зарегистрировать сам доступ к данным. Например:

App 
|| 
V 
Log 
|| 
V 
Data=>Log 

Я могу рискнуть попасть в цепь обратной связи? Если да, то как мне его избежать? Могут ли ссылки на проектный цикл друг на друга и создавать трудности при построении? Как вы успешно подошли к этому (анти?) Шаблону в прошлом?

Answer 1

Создайте сборку (или сборки в зависимости от обстоятельств), которая содержит только интерфейсы. Ссылка на сборку интерфейса только из ваших конкретных классов классов и каждый конкретный класс реализует один или несколько интерфейсов. Не используйте конкретные сборки классов для других конкретных классов классов, которые являются частью вашего решения.

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

Внесите dependency injection/inversion of control container, например StructureMap или одну из многих других доступных вам возможностей .NET, чтобы уменьшить сцепление еще больше.

Answer 2

? Возможно более упрощенное решение:

public interface ILoggable { 
    string ToLogFormat(); 
} 

Затем реализуют этот интерфейс на любой объект, который может быть зарегистрирован. Уровень регистрации теперь зависит только от интерфейса и может использоваться на любом уровне.

альтернативой является использование «вспомогательных» классов для реализации ToLogFormat посредством перегрузки, например.

public class LogHelper { 
    public string ToLogFormat(DAO obj) { ... } 
    public string ToLogFormat(SomeOtherClass obj) { ... } 
    ... 
} 

вы можете использовать один монолитный помощник журналу (что плохо, потому что он должен ссылаться на каждую библиотеку), но лучшее решение может стать реализация хелпер журнала для каждого узла или класса и указать имя журнала класс -helper с использованием специального атрибута

лично я предпочитаю подход ILoggable как более гибкий; ваш пакет регистрации может иметь простую функцию:

public class Logger { 
    public string ToLogFormat(object obj) { 
     if (obj is ILoggable) { 
      return ((ILoggable)obj).ToLogFormat(); 
     } 
     return obj.ToString(); 
    } 
}