如何防止泄漏抽象？

我在写一个Active Directory包装器，试图遵循SOLID和其他最佳实践。界面目前是“IActiveDirectory”。如何防止泄漏抽象？

我现在的问题是，实现ActiveDirectory必须实现IDisposable来处置创建和处理这个包装内的一些资源，我不知道如何解决这个问题，而试图编码到接口等等......我不想创建一个漏洞抽象（即装饰IActiveDirectory w/IDisposable）。我不能将服务细化（即将方法调用创建/处理资源的范围设置为方法调用），这是由于底层的依赖关系。

我目前有一个工厂，以便IActiveDirectory的消费者可以创建一个按需，但我需要一个干净，方便的方式让消费者用信号完成资源。

如何在不泄漏资源包装的抽象的情况下向消费者提供合同（即接口）？我应该公开实现sans一个接口吗？我的消费者或我的DI容器是否有办法管理此服务的生命周期？

来源

2013-11-01 Martin Bliss

“我需要一个干净，方便的方式让消费者用信号完成信号。” - 这正是“IDisposable”的意思。你不能抽象所有*。 – delnan

是的，我知道这正是IDisposable是什么，我没有问题把它放在具体的类。然而，我不喜欢把它放在一个接口上，因为我创建了一个漏洞抽象，我假设所有的实现都需要一个Dispose方法调用，违反了Liskov。你认为只是将具体的sans接口暴露出来会更好吗？ –

这是完全有效的，在LSP和其他条件下，“Dispose”什么也不做。把它放在一个接口上并不意味着假设所有的实现都需要配置（任何不能简单地添加'void Dispose（）{}'）的实现，这意味着假设*一些实现需要配置（这是真实的）。 – delnan

一方面，处置资源的责任落在获得资源的人身上。您的客户端不会创建ActiveDirectory，工厂不会 - 因此在概念上，工厂必须处理ActiveDirectory。

这很难，但可以实现。 Web应用程序的一个示例是，您可以将工厂范围限制为请求范围，并且在请求完成时安全地将其置于活动目录中。另一个例子是当你的实例由IoC容器管理时，它知道如何处理IDisposable（NInject有一些棘手的黑客来做这件事）。然后，如果这不适用于你，你应该承认通用解决方案不是最高性能的（这根本不奇怪），如果你仍然想抽象，你可以创建额外的抽象IActiveDirectorySession其中明确表示与AD的通信会话，并且由于非常自然的原因必须实现IDisposable，至少。

来源

2013-11-01 21:22:29 ovolko

我的想法。我已经使用了环境上下文模式来创建一个准会话，通过该会话，在调用上下文的Dispose时，在服务的保护下创建的任何对象都将被“注册”以进行处理。在这种情况下，使用IoC来管理生命期实际上是不可能的，因为我认为在需要很长时间之前打开“会话”并关闭很长时间是不可接受的。 –

如何防止泄漏抽象？

回答

相关问题