Для ведения журнала межсекторального взаимодействия необходим доступ к уровню данных
Скажем, у меня есть архитектура, похожая на образец многоуровневой архитектуры. Давайте также предположим, что каждая большая коробка - это собственный проект. Рамка Frameworks и каждый слой будут тогда его собственным проектом. Если мы не используем IoC и вместо этого используем традиционный многоуровневый подход без интерфейсов, Service будет ссылаться на Business, который будет ссылаться на Data, и все они будут ссылаться на Frameworks.
Теперь требуется, чтобы протоколирование выполнялось в базе данных, поэтому, предположительно, Frameworks должна будет ссылаться на Service для доступа к данным. Есть две проблемы с этим:
- Теперь у вас есть круговая зависимость (помните, нет интерфейсов). Большая часть этого может быть решена, если вы используете интерфейсы с IoC (Dependency Injection или Service Locator) и корнем композиции. Это единственный способ или можно как-то сделать без интерфейса?
- Если вы находитесь в Бизнесе и вам нужно что-то зарегистрировать, он должен снова перейти на обслуживание. Есть ли способ сделать переход только из презентации, но не из службы / бизнеса / данных без корня композиции?
Я знаю, что немного отвечаю на свой вопрос, но я в основном хочу понять, возможна ли вообще эта архитектура без IoC.
3 ответа
Без некоторой инверсии контроля вы не сможете ничего сделать.
Предполагая, что ваш язык поддерживает что-то вроде Reflection в.NET, вы можете попытаться динамически вызывать код и инвертировать элемент управления во время выполнения. Вам не нужны интерфейсы, но вам, возможно, придется пометить / декорировать или иметь соглашение для типов, которые вам нужны на верхних уровнях.
Сейчас я просто думаю о сумасшедших непрагматичных подходах: вы можете пост-обработать двоичный файл и внедрить код регистрации в каждом слое.
В этом примере я бы вызвал методы ведения журнала на бизнес-уровне, где необходимо ведение журнала. На самом деле не имеет никакого смысла вызывать уровень. Это было бы ненужной абстракцией, и похоже, что вы собрали столько же.
Есть ли какая-либо абстракция, предоставляемая на уровне служб для ведения журнала, которая потребуется при входе на бизнес-уровень? Если это так, возможно, какой-то фасад может быть создан с целью ведения журнала бизнес-уровня. Если вам не требуется эта абстракция, я бы вызвал методы ведения журнала напрямую.
IMO, поскольку ведение журнала является сквозной задачей, оно не должно ссылаться на ваш уровень данных. В вашем вопросе я вижу, что вы предполагали, что входите в базу данных. Даже если это ваше требование, вы должны поддерживать соединение с базой данных / вставку кода записей журнала отдельно от уровня данных вашего приложения. Он будет частью вашей библиотеки журналов, а не частью уровня данных. НЕ рассматривайте это как часть уровня данных. Именно с этой точки зрения вы можете продолжать разрабатывать / улучшать [каркас] ведения журналов, а также он будет отделен от вашего уровня данных.
С моей точки зрения, уровень данных состоит только из доступа к данным приложения, а не регистрации. Конкретно вы можете увидеть библиотеки NLog или Log4Net и посмотреть, как они не связаны со стратегией уровня доступа к данным в Приложении.
Надеюсь это поможет.