有流畅界面的经验吗？我需要你的意见！

抱歉这个很长的问题，它被标记为维基百科，因为我要求的东西可能没有非常具体的答案。既然关了，那就这样吧。

我的主要问题是：

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

我正在进行第三次重写 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");

所以我想构建流畅的界面，以便在您指定之后how要解决某个服务，您不能再这样做。

• 换句话说，流畅的界面非常易于使用，因为它们会引导您做什么。

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

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

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

等等，但对我来说这看起来是支离破碎的。

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

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

如果您有兴趣，这里有一些我的经验积累中的提示流畅的NHibernate http://fluentnhibernate.org.

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

例如，死胡同：

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)

Versus:

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

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

对于非英语母语人士来说，您的界面也变得更加难以使用。虽然大多数非母语人士都知道他们要查找的内容的技术术语，但他们可能不清楚额外的单词。