我正在思考一个C#库的设计,它将有几个不同的高级函数.当然,这些高级功能将尽可能使用SOLID类设计原则来实现.因此,可能存在供消费者定期直接使用的类,以及作为那些更常见的"最终用户"类的依赖性的"支持类".

问题是,设计库的最佳方法是:

• DI不可知 - 虽然为一个或两个常见的DI库(StructureMap,Ninject等)添加基本的"支持"似乎是合理的,但我希望消费者能够将该库与任何DI框架一起使用.
• 非DI可用 - 如果库的使用者没有使用DI,那么库应该仍然尽可能容易使用,减少了用户为创建所有这些"不重要"的依赖关系而必须完成的工作量.他们想要使用的"真实"类.

我目前的想法是为常见的DI库提供一些"DI注册模块"(例如,一个StructureMap注册表,一个Ninject模块),以及一个非DI的集合或工厂类,并包含与这几个工厂的耦合.

思考？

我有一个Web服务,它将传递一些数据(特别是来自SharePoint文档库的InfoPath xml).我目前正在使用Ninject来处理要加载的数据"策略".这是一些代码(问题如下):

网络服务(入口点)

namespace Web.Services
{
    public bool AddForm(XmlDocument form, string formName)
    {
        IKernel kernel = new StandardKernel(new FormsModule());
        var ctx = kernel.Get<IPFormDataContext>(formName);

        return ctx.DoWork(form);
    }
}

Ninject相关事物

namespace Core.Modules
{
    public class FormsModule : NinjectModule
    {
        public override void Load()
        {
            Bind<IPFormDataContext>().ToSelf().Named("FormA");
            Bind<IPFormDataContext>().ToSelf().Named("FormB");
            // Snip

            Bind<IPFormDataStrategy>().To<FormAStratgey>()
                .WhenParentNamed("FormA");
            Bind<IPFormDataStrategy>().To<FormBStrategy>()
                .WhenParentNamed("FormB");
            // Snip
        }
    }
}

模式相关的事情

namespace Core.Forms
{
    public class IPFormDataContext
    {
        private IPFormDataStrategy _ipFormDataStrategy;

        public IPFormDataContext(IPFormDataStrategy strategy)
        {
            _ipFormDataStrategy = strategy;
        }

        public bool DoWork(XmlDocument form)
        {
            return …