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

Question

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

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

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

Answer 1

возможно слишком упрощенное решение:

public interface ILoggable {
    string ToLogFormat();
}

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

альтернатива - использовать вспомогательные классы для реализации ToLogFormat через перегрузку, например,

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

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

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

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

Answer 2

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

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

Внедрение внедрения зависимостей / инверсия контейнера управления подобно StructureMap или одна из многих других доступных опций .NET для еще большего уменьшения связи.