自定义提供程序、最佳实践和配置配置答案

【问题标题】：Custom Providers, Best Practices, and Configuration Conflaguration自定义提供程序、最佳实践和配置配置
【发布时间】：2009-08-11 12:07:58
【问题描述】：

我已经使用 ASP.NET 构建网站已有一段时间了。起初，我避免学习 ASP.NET 提供程序模型的复杂性。相反，我在必要时使用了罐装提供程序，并严重依赖依赖注入框架来满足我的所有其他需求。

然而，最近，我一直在为 ASP.NET 编写可插入组件，当然也编写了许多基于自定义提供程序的解决方案以实现这一目标。然而，我很快就发现很多initialization code is being duplicated，这是一件坏事。

所以……

在如何避免配置意大利面条式代码方面出现了任何最佳实践？
您是否已构建或有任何示例（基类/帮助类、自定义属性、反射）来分享抽象基本初始化代码以便更轻松地构建自定义提供程序？

注意：

请不要尝试将我发送到Provider Toolkit 站点。我已经用尽了那个资源，这就是我转向 SO 社区的原因:)

【问题讨论】：

我想提供一些帮助，但我不是很清楚。您正在为 ASP.NET 编写“可插入组件”，并且“当然”正在编写许多基于提供程序的自定义解决方案......我不确定您所说的可插入组件究竟是什么意思，或者为什么很明显您会编写不同的提供程序对于每个组件。您能否阐明您正在尝试做什么，以及为什么您需要为每个组件提供不同的提供程序？我会看看能不能提供一些帮助。
你见过ELMAH吗？我一直在努力编写与其关注点交叉的组件，但不是特定于域/应用程序的。模块、处理程序等......如果他们接触到任何类型的存储，他们需要利用提供者模型来实现真正的可插拔（machine.config/web.config）。这不是问题，但我注意到您最终编写了大量代码来管理配置内容。我只是想知道是否有人这样做足以提出一些最佳实践，甚至是一些通用处理此类管道代码的实用方法。
这就像在 Web 环境中用于缓存的双重锁定模式。如果您对缓存做任何事情，您最终会编写该代码，但您通常会将其分解为一些实用程序类来为您完成繁重的工作，因此您不必编写两次。在管理配置部分时，您最终会做很多事情，我只是想知道是否专门针对此问题出现了任何模式。我只想尽可能干。

标签： asp.net provider

【解决方案1】：

我只是粗略地实现了成员资格和角色提供者的相当基本的实现，我根本没有任何代码重复！

我已将所有内容分为三个项目（加上测试）：

应用程序 - asp.net mvc 应用程序。模型、控制器等。
基础架构 - IoC 和接口
Infrastructure.Web - 提供者

User 和 Role 的模型实现来自 Infrastructure 的接口，并且这些类在应用程序启动时注册到 IoC。然后，提供者要求 IoC 解决这些类并做这件事。通过这种方式，我可以使用相同的提供程序向模型和用户界面添加内容。我注意到的一个问题是，由“ASP.NET 配置”按钮启动的 Web 无法使用提供程序，因为设置是在 Application_Start 中完成的，而“ASP.NET 配置”是另一个 Web .不过我不认为这是个问题。

【讨论】：

我专门尝试构建可插入任何 ASP.Net 项目的可插入组件。我很想使用 IoC，但这会排除可以将单个 DLL 放入项目并工作的能力。
在您的组件中包含一个迷你 IoC，让应用注册一个在您的组件中实现接口的工厂，并公开构建相应类的方法。