哪一种模式用于登录？依赖注入或服务定位器？ [英] Which pattern to use for logging? Dependency Injection or Service Locator?

问题描述

考虑这种情况。我有一个现在，然后将需要写入日志一些业务逻辑。

Consider this scenario. I have some business logic that now and then will be required to write to a log.

interface ILogger
{
    void Log(string stuff);
}

interface IDependency
{
    string GetInfo();
}

class MyBusinessObject
{
    private IDependency _dependency;

    public MyBusinessObject(IDependency dependency)
    {
        _dependency = dependency;
    }

    public string DoSomething(string input)
    {
        // Process input
        var info = _dependency.GetInfo();
        var intermediateResult = PerformInterestingStuff(input, info);

        if (intermediateResult== "SomethingWeNeedToLog")
        {
            // How do I get to the ILogger-interface?
        }

        var result = PerformSomethingElse(intermediateResult);

        return result;
    }
}

你将如何获得ILogger接口？我看到两个主要的可能性;

How would you get the ILogger interface? I see two main possibilities;

1. 使用的构造函数依赖注入它传递


2. 获取它。通过一个单独的服务定位器。

哪种方法你更喜欢，为什么？还是有一个更好的模式？

Which method would you prefer, and why? Or is there an even better pattern?

更新：
请注意，我并​​不需要记录所有的方法调用。我只是想记录可能会或可能不是我的方法中出现的一些（罕见）事件。

Update: Note that I don't need to log ALL method calls. I only want to log a few (rare) events that may or may not occur within my method.

推荐答案

我个人做了。两者的混合

I personally do a mixture of both.

下面是我的约定：

• 发件人静态上下文 - 服务定位


• 从实例上下文 - 依赖注入

• From a static context - Service Location
• From an instance context - Dependency Injection

我觉得这给了我可测性的最佳平衡。我觉得有点难以对使用服务定位不是使用DI类设置的测试，所以这就是为什么服务定位最终是例外而非规则。我在它的使用一贯的，虽然如此，它不是很难记住我需要写什么类型的测试。

I feel this gives me the right balance of testability. I find it a little harder to setup tests against classes that use Service Location than use DI, so this is why Service Location ends up being the exception rather than the rule. I'm consistent in its use, though, so it's not hard to remember what type of test I need to write.

有人提出，DI趋于杂乱的关注构造函数。我不觉得这是一个问题，但如果你有这样的感觉，有一些使用DI的替代品，但要避免构造函数的参数。下面是Ninject的DI方法列表：
http://ninject.codeplex.com/wikipage?title =注射％20Patterns

Some have raised the concern that DI tends to clutter constructors. I don't feel this is a problem, but if you feel this way, there are a number of alternatives that use DI, but avoid constructor parameters. Here is a list of Ninject's DI methods: http://ninject.codeplex.com/wikipage?title=Injection%20Patterns

您会发现，控制容器的反转大多具有相同的功能，Ninject。我选择了展示Ninject因为他们有最简洁的样本。

You'll find that most Inversion of Control containers have the same features as Ninject. I chose to show Ninject because they have the most concise samples.

希望这是有帮助的。

编辑：需要明确的是，我用团结和公共服务定位​​器。我有我的DI容器团结和我的执行IServiceLocator中的单一实例仅仅是围绕单身团结容器的包装。这样，我没有做任何类型映射两次或类似的东西。

To be clear, I use Unity and Common Service Locator. I have a singleton instance of my Unity container for DI and my implementation of IServiceLocator is simply a wrapper around that singleton Unity container. This way I don't have to do any type mappings twice or anything like that.

我还没有找到AOP是超越跟踪特别有用。我喜欢手动记录更简单的清晰。我知道，大多数AOP日志框架均可进行，但我不需要前（AOP的面包和奶油）的大部分时间。这当然只是个人喜好，

I also don't find AOP to be particularly helpful beyond tracing. I like manual logging better simply for its clarity. I know that most AOP logging frameworks are capable of both, but I don't need the former (AOP's bread and butter) most of the time. This is just personal preference, of course.

这篇关于哪一种模式用于登录？依赖注入或服务定位器？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！