4

抱歉这个长问题，它被标记为 wiki，因为我要求的东西可能没有非常具体的答案。如果它关闭了，那就这样吧。

我的主要问题是：

您将如何编写一个未在基类中完全定义的流畅接口，以便使用流畅接口的程序可以在现有结构中添加新词，并仍然保持引导界面，以便在点之后，智能感知仅列出此时实际应用的关键字。

我正在进行第三次重写 IoC 容器的迭代。第二次迭代是为了提高性能，第三次迭代将解决一些可扩展性问题和分离问题。

基本上，可扩展性的问题是没有。我最近想使用一个有生命周期的服务，在生命周期结束后，解析一个新副本。例如，每分钟读取一个配置文件，但不会更频繁。我当前的 IoC 解决方案不支持这一点，但添加它的唯一方法是进入基类库并在那里添加对它的支持。这对我来说意味着我未能构建可扩展的类库。平心而论，我并不打算在其中构建可扩展性，但是我并没有完全意识到稍后再添加这样的东西会有多痛苦。

我正在查看我的流利配置界面，因为我也想在界面中构建完整的可扩展性（或摆脱它，我不愿意这样做），我需要以不同的方式做事。

因此，我需要你的意见。我实际上使用流畅接口的经验很少，但我见过很多使用它们的代码，因此开箱即用有一个明显的好处：

  • 使用流畅接口的代码通常很容易阅读

换句话说，这：

ServiceContainer.Register<ISomeService>()
    .From.ConcreteType<SomeService>()
    .For.Policy("DEBUG")
    .With.Scope.Container()
    .And.With.Parameters
        .Add<String>("connectionString", "Provider=....")
        .Add<Boolean>("optimizeSql", true);

比这更容易阅读：

ServiceContainer.Register(typeof(ISomeService), typeof(SomeService),
    "DEBUG", ServiceScope.Container, new Object[] { "Provider=...", true });

所以可读性是一个问题。

然而，程序员指导是另一回事，通过阅读现有代码、在网络上或在编辑器中不容易理解。

基本上，当我输入以下内容时：

ServiceContainer.Register<ISomeService>()
    .From.|
          ^-cursor here

然后智能感知将显示可用的分辨率类型。在我选择了那个之后，然后写：

ServiceContainer.Register<ISomeService>()
    .From.ConcreteType<SomeService>()
    .For.|

然后我只能在“For”关键字之后获得可用的东西，例如“Policy”等。

然而，这是一个大问题吗？你用过的流畅的界面是这样的吗？定义接口的明显方法是创建一个包含所有关键字和所有内容的类或接口，以便每个逗号后的智能感知包含所有内容，但这也可能导致这是合法的（例如，它编译）代码：

ServiceContainer.Register<ISomeService>()
    .From.ConcreteType<SomeService>()
    .From.Delegate(() => new SomeService())
    .From.With.For.Policy("Test");

所以我想构建流畅的接口，这样在你指定如何解析服务之后，你就不能再这样做了。

  • 换句话说，流畅的界面非常易于使用，因为它们会引导您完成您可以做的事情。

但这是典型的吗？由于我希望能够添加一堆这样的关键字，比如解析器的类型（ConcreteType、Delegate等）、作用域的类型（Factory、Container、Singleton、Cache等）作为扩展方法，这样程序可以定义自己的方式来做到这一点，而无需进入并更改基类，这意味着我需要为所有中间停止提供接口，并让实际重要的关键字成为。然后，这些关键字的实现必须根据需要选择一个要返回的中间停止接口。

所以看起来我需要定义一个接口：

  • xyz.来自。
  • xyz.From.<Resolver here>.
  • <Resolver here>.With.
  • <Resolver here>.For.

等等，但这在我看来是支离破碎的。

任何有流畅界面经验的人都可以回去阅读我在顶部附近引用的答案并尝试给我一个简短的答案吗？

4

2 回答 2

6

两件事：扩展方法和嵌套闭包。它们应该涵盖您所有的可扩展性和智能感知清晰度需求。

如果您有兴趣，这里有一些来自我构建Fluent NHibernate的经验的提示。

方法链应保持在最低限度。除其他外，它会导致调用链的死胡同和无限期结束。更喜欢嵌套闭包。

例如，死胡同：

Database
  .ConnectionString
    .User("name")
    .Password("xxx")
  .Timeout(100) // not possible

Database进入链后，您将无法返回ConnectionString链，因为所有与连接字符串相关的方法都无法返回ConnectionString.

你可以用确定结束的方法重写它，但它们很丑。

Database
  .ConnectionString
    .User("name")
    .Pass("xxx")
    .Done()
  .Timeout(100)

在这种情况下，Done将返回Database实例，将您返回到主链。再次，丑陋。

正如建议的那样，更喜欢嵌套闭包。

Database
  .ConnectionString(cs =>
    cs.User("name");
      .Pass("xxx"))
  .Timeout(100);

这几乎涵盖了您的智能感知问题，因为闭包是相当独立的。您的顶级对象将仅包含采用闭包的方法，而这些闭包仅包含特定于该操作的方法。可扩展性在这里也很容易，因为您可以将扩展方法仅添加到闭包内公开的类型。

您还应该注意不要试图让您的流利界面读起来像英语。 UseThis.And.Do.That.With.This.BecauseOf.That当动词足够时，链条只会使您的界面复杂化。

Database
  .Using.Driver<DatabaseDriver>()
  .And.Using.Dialect<SQL>()
  .If.IsTrue(someBool)

相对：

Database
  .Driver<DatabaseDriver>()
  .Dialect<SQL>()
  .If(someBool)

智能感知中的可发现性降低了，因为人们倾向于寻找动词却找不到它。FNH 的一个例子是WithTableName方法，人们倾向于寻找单词table而没有找到它，因为方法以开头。

您的界面也变得更难用于非英语母语人士。虽然大多数非母语人士会知道他们正在寻找的技术术语，但他们可能不清楚额外的单词。

于 2009-12-28T17:27:51.100 回答
0

根据@James Gregory提供的答案，我为我的 IoC 容器创建了一个新的原型流畅接口，这就是我最终得到的语法。

这解决了我目前的问题：

  1. 可扩展性，我可以通过扩展方法添加新的分辨率类型、新的范围类型等
  2. 易于编写流畅的界面，无需重复导致相同路径后缀的关键字
  3. 与我的第 1 次和第 2 次迭代实现相比，代码要少得多

所有代码都在我的沙箱中编译，所以它们都是合法的语法，没有任何东西被伪造，除了这些方法当然现在什么都不做。

我决定不修复的一件事是流畅界面的引导部分，它限制了您在界面上移动时的选择。因此，这样写是完全有效的：

IoC.Register<ILogger>()
    .From(f => f.ConcreteType<TestLogger>())
    .From(f => f.ConcreteType<AnotherLogger>()); // note, two From-clauses

大概我将不得不选择这是否引发异常（已设置解析对象）或最后一个获胜。

请留下评论。

这是代码：

using System;

namespace IoC3rdIteration
{
    public class Program
    {
        static void Main()
        {
            // Concrete type
            IoC.Register<ILogger>()
                .From(f => f.ConcreteType<TestLogger>());

            // Concrete type with parameters
            IoC.Register<ILogger>()
                .From(f => f.ConcreteType<DatabaseLogger>(ct => ct
                    .Parameter<String>("connectionString", "Provider=...")
                    .Parameter<Boolean>("cacheSql", true)));

            // Policy
            IoC.Register<ILogger>()
                .From(f => f.ConcreteType<TestLogger>())
                .Policy("DEBUG");

            // Policy as default policy
            IoC.Register<ILogger>()
                .From(f => f.ConcreteType<TestLogger>())
                .Policy("RELEASE", p => p.DefaultPolicy());

            // Delegate
            IoC.Register<ILogger>()
                .From(f => f.Delegate(() => new TestLogger()));

            // Activator
            IoC.Register<ILogger>()
                .From(f => f.Activator("IoC3rdIteration.TestService"));

            // Instance
            IoC.Register<ILogger>()
                .From(f => f.Instance(new TestLogger()));

            // WCF-wrapper
            IoC.Register<ILogger>()
                .From(f => f.WCF());

            // Sinkhole service
            IoC.Register<ILogger>()
                .From(f => f.Sinkhole());

            // Factory
            IoC.Register<IServiceFactory<ILogger>>()
                .From(f => f.ConcreteType<LoggerFactory>());
            IoC.Register<ILogger>()
                .From(f => f.Factory());

            // Chaining
            IoC.Register<IDebugLogger>()
                .From(f => f.ConcreteType<DatabaseLogger>());
            IoC.Register<ILogger>()
                .From(f => f.ChainTo<IDebugLogger>());
                // now "inherits" concrete type

            // Generic service
            IoC.Register(typeof(IGenericService<>))
                .From(f => f.ConcreteType(typeof(GenericService<>)));

            // Multicast
            IoC.Register<ILogger>()
                .From(f => f.Multicast(
                    r1 => r1.From(f1 => f1.ConcreteType<TestLogger>()),
                    r2 => r2.From(f2 => f2.Delegate(() => new TestLogger())),
                    r3 => r3.From(f3 => f3.Instance(new DebugLogger()))));

            // Factory-scope
            IoC.Register<ILogger>()
                .From(f => f.ConcreteType<TestLogger>())
                .Scope(s => s.Factory());

            // Thread-scope
            IoC.Register<ILogger>()
                .From(f => f.ConcreteType<TestLogger>())
                .Scope(s => s.Thread());

            // Session-scope (ASP.NET)
            IoC.Register<ILogger>()
                .From(f => f.ConcreteType<TestLogger>())
                .Scope(s => s.Session());

            // Request-scope (ASP.NET)
            IoC.Register<ILogger>()
                .From(f => f.ConcreteType<TestLogger>())
                .Scope(s => s.Request());

            // Singleton-scope
            IoC.Register<ILogger>()
                .From(f => f.ConcreteType<TestLogger>())
                .Scope(s => s.Singleton());

            // Singleton-scope with lifetime
            IoC.Register<ILogger>()
                .From(f => f.ConcreteType<TestLogger>())
                .Scope(s => s.Singleton(si => si.LifeTime(10000)));

            // Container-scope
            IoC.Register<ILogger>()
                .From(f => f.ConcreteType<TestLogger>())
                .Scope(s => s.Container());

            // Container-scope with lifetime
            IoC.Register<ILogger>()
                .From(f => f.ConcreteType<TestLogger>())
                .Scope(s => s.Container(c => c.LifeTime(10000)));

            // Pooled-scope
            IoC.Register<ILogger>()
                .From(f => f.ConcreteType<TestLogger>())
                .Scope(s => s.Pool(p => p
                    .Minimum(1)             // always one instance in pool
                    .Typical(5)             // reduce down to 5 if over 5
                    .Maximum(10)            // exception if >10 in pool
                    .AutoCleanup()          // remove on background thread >5
                    .Timeout(10000)));      // >5 timeout before removal
        }
    }
}
于 2009-12-29T10:02:19.330 回答