需要替代提供者模式 [英] need an alternative to the provider pattern

查看:127
本文介绍了需要替代提供者模式的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

为了配置,我正在维护一个利用提供者模式的Web应用程序,如下所述。

I'm maintaining a web application that utilizes the provider pattern as described below, for configuration purposes.

http:/ /msdn.microsoft.com/en-us/library/ms972319.aspx

http://msdn.microsoft.com/en-us/library/ms972370.aspx

一切都已经工作正常,但随着我们为应用程序添加功能,我们发现我们的提供商已经成为不属于一起的几个不同功能的混搭。我们正在考虑分解配置提供程序,以使类似的功能与其他类似功能组织起来。我们正在这样做,因为我们原来的提供商现在有一些功能,不需要由某些模块实现。实现提供程序时,不要仅仅将UnImplementedException抛弃在外部函数上,而是根本不包括它们。

Everything has been working fine, but as we add functionality to our application, we are finding that our provider has become a mash up of several different functions that do not belong together. We are contemplating splitting up the configuration provider so that like functions are organized with other like functions. We're doing this because our original provider now has a handful of functions that do not need to be implemented by some modules. Instead of just throwing NotImplementedException on the extraneous functions when implementing the provider, we would like to just not include them at all.

我们意识到我们可以使用上述MSDN方法创建多个提供程序,但是多个提供者只需在web.config中创建更多条目。最好把web.config中的条目减到最小,因为它开始变大了。

We realize that we could create multiple providers using the above MSDN method, but multiple providers would just create more entries in the web.config. It would be nice to minimize entries in the web.config, since that is starting to get big.

有没有人找到实现提供者模型的另一种方法?

Has anyone found another way to implement the provider model?

推荐答案

您可以使用控制反转(IoC)容器(GoogleCastle Windsor或StructureMap,或AutoFac或NInject或Microsoft Unity)查看。使用IoC,您可以在配置文件中或应用程序开始时配置providers。

You could look at using an inversion of control (IoC) container (Google "Castle Windsor", or StructureMap, or AutoFac, or NInject, or Microsoft Unity). Using an IoC you can either configure the "providers" in a configuration file or at the beginning of your application.

通常,您将为每种类型的提供者创建接口。使用界面,您可以轻松地分解您的提供商,但对您来说是有意义的。

Typically you would create interfaces for each type of provider that you have. Using interfaces you could easily break up your providers however it made sense to you.

一旦你有接口,你可以简单地问容器在实现该接口时需要它,并且容器会为你提供一个实例化的提供者。

Once you have the interfaces in place you could simply ask the container for an implementation of that interface when you need it and the container will take care of instantiating a provider for you.

这篇关于需要替代提供者模式的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆