Ninject和打包服务,基础架构和数据层 [英] Ninject and packaging service, infrastructure and data layers

查看:62
本文介绍了Ninject和打包服务,基础架构和数据层的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我是ninject的忠实粉丝.但是到目前为止,我仅将其用于单个应用程序注入.我目前想打包我创建的服务基础结构和数据层.

I am a HUGE fan of ninject. To date however I have only used it for single application injections. I currently want to package up my services infrastructure and data layers that I have created.

基本上,我的基础结构层具有创建存储过程Dao的契约,我的服务层需要将该契约传递给数据层.数据层使用添加到DAO中的参数进行SP调用,并返回数据集.所有这些都非常出色.

Basically my infrastructure layer has the contracts for creating the stored procedure Dao's that my services layer needs to pass to the data layer. The data layer does the SP call with the parameters added to the DAO and returns a dataset. All of this works excellently.

我对所有三个函数都使用基于构造函数的依赖项注入,我想将它们与IOC一起预打包.这样,当我在其他应用程序中使用它们时,不必重新连接dll中类的依赖项注入.

I use constructor based dependency injection on all three of them and I would like to prepackage the IOC with them. That way when I use them in another application I do not have to rewire the dependency injection for the classes in the dll.

每次我当前使用ninject时,都会连接一个ninject Webcommon,该Webcommon从上到下执行整个应用程序.

Every time I have currently used ninject, I wire up a ninject webcommon that does the entire application top to bottom.

namespace MyApp.App_Start
{
    using System;
    using System.Web;

    using Microsoft.Web.Infrastructure.DynamicModuleHelper;

    using Ninject;
    using Ninject.Web.Common;

    public static class NinjectWebCommon 
    {
        private static readonly Bootstrapper bootstrapper = new Bootstrapper();

        /// <summary>
        /// Starts the application
        /// </summary>
        public static void Start() 
        {
            DynamicModuleUtility
                .RegisterModule(typeof(OnePerRequestHttpModule));

            DynamicModuleUtility
                .RegisterModule(typeof(NinjectHttpModule));

            bootstrapper.Initialize(CreateKernel);
        }

        /// <summary>
        /// Stops the application.
        /// </summary>
        public static void Stop()
        {
            bootstrapper.ShutDown();
        }

        /// <summary>
        /// Creates the kernel that will manage your application.
        /// </summary>
        /// <returns>The created kernel.</returns>
        private static IKernel CreateKernel()
        {
            var kernel = new StandardKernel();
            AutoMapper.AutoMapperConfigurator.Configure();

            try
            {
                kernel.Bind<Func<IKernel>>()
                    .ToMethod(ctx => () => new Bootstrapper().Kernel);
                kernel.Bind<IHttpModule>()
                    .To<HttpApplicationInitializationHttpModule>();

                RegisterServices(kernel);
                return kernel;
            }
            catch
            {
                kernel.Dispose();
                throw;
            }
        }

        /// <summary>
        /// Load your modules or register your services here!
        /// </summary>
        /// <param name="kernel">The kernel.</param>
        private static void RegisterServices(IKernel kernel)
        {
            kernel.Bind<IQuerySelector>().To<QuerySelector>();
            kernel.Bind<IQueryExecutor>().To<QueryExecutor>();
            kernel.Bind<ISqlParameterPopulationService>()
                .To<SqlParameterPopulationService>();
        }        
    }

我希望开发人员无法访问预包装的Dll中的一个IOC,然后用户可以拥有自己的IOC,以便将所有注射添加到其中.

I would like one IOC in my prepackaged Dll's that the developer doesn't access and then the user can have her/his own IOC that they would add all of their injections to.

推荐答案

这是可行的.

我通常创建一个单独的"CompostionRoot"项目,该项目本身引用我的中央界面和具体的业务/服务/数据层等,然后向其添加Ninject,将该项目的引用添加至我的MVC/WebAPI项目,然后最后在 RegisterServices 函数

I usually create a separate "CompostionRoot" project, which itself references my central interface and concrete business/service/data layers, etc, then add Ninject to it, add a reference to this project to my MVC/WebAPI project, then finally pass the kernel from Ninject.Web.Common in the RegisterServices function

using CompositionRoot; 
...
...

private static void RegisterServices(IKernel kernel)
        {
            var cr = new MyExternalComposer(kernel);
            cr.DoBindings();
        }  

现在这可能不被认为是最佳实践",但是我喜欢这种方法的是,我完全不依赖MVC项目中的具体业务/服务/数据层实现-一切都可以通过接口来完成从MVC项目引用我的Interfaces项目,并且该项目可以在其他解决方案中重复使用.我想这只是间接的额外一层,到目前为止,我还没有遇到过这种作法的任何弊端...

Now this might not be considered "best practice" but what I like about that approach is that I have no dependencies at all on concrete business/service/data layer implementations from my MVC project - everything can be done by interface by just referencing my Interfaces project from the MVC project, plus the project can be re-used in other solutions. It's just an extra layer of indirection I suppose and I haven't come across any drawbacks from doing it this way so far...

希望有帮助.

这篇关于Ninject和打包服务,基础架构和数据层的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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