0

我有一个由我的同事继承的业务逻辑操作的基类。此类公开一个需要objectContextas 参数的构造函数。您可以将此基类视为原子 CRUD 操作的组件（其所有选择、插入、编辑和删除方法将始终只作用于一个实体）。

然后，我有一个“超类”，其主要目的是objectContext在所有上述基类之间共享，以便执行某些业务事务，并且如果需要，它还必须提供任何baseClass实例。

所以，我正在寻找一种优雅的方式将超类“注入”objectContext到baseclass：

public BaseClass<T> where T : entity
{
    private ObjectContext _ctx;
    public BaseClass(ObjectContext ctx){ _ctx = ctx;}
    public virtual IList<T> Select(){..}
    public cirtual voind Insert(T entity){..}
    // other stuff 
}

public class SuperClass
{
    private ObjectContext _ctx = new...
    public BaseClass<TEntity> LoadBaseClass(TBase, TEntity) where TBase : BaseClass<TEntity>, where TEntity : class
    {
        BaseClass<TEntity> obj = Activator.CreateInstance(typeof(TBase), _ctx); // share objectContext
    }
    public int SaveAll(){return _ctx.SaveChanges();}
}

如您所见，我的超类能够baseClass通过其类型返回一些实例，这正是我想要的。但是，如果某个继承的类使用其他参数定义了自己的构造函数，我的LoadBaseClass方法将失败。

我会找到一个干净的解决方案，以避免在从LoadBaseClass方法创建实例期间出现任何错误的可能性。我知道的唯一方法是定义一个私有构造函数，但是通过这种方式，没有人能够再继承baseclass了..

4

1 回答 1

2

您正在寻找的是所谓的Dependency Injection。您现在正在尝试手动构建它，但是已经有很多工具可以满足您的需求。

依赖注入是关于构造对象和配置这些对象的创建方式和时间。它归结为将对象创建从您的业务逻辑中分离出来。

在您的情况下，您正在使用称为工作单元和存储库模式的东西。使用像Ninject这样的依赖注入容器，您可以轻松地将您的配置UnitOfWork为在所有存储库之间共享，如下所示：

var kernel = new StandardKernel();
kernel.Bind<IMyRepository>().To<ConcreteRepository();
kernel.Bind<IMyUnitOfWork>().To<ObjectContextImp>().InRequestScope();

IMyRepository repos = kernel.Get<IMyRepository>();

Ninject（或任何 DI 工具）会尝试构建一个IMyRepository. 您已将其配置为查找ConcreteRepository. 然后它注意到它的构造函数中ConcreteRepository接受了 a 。IMyUnitOfWork在这种情况下，您已将其映射到您的ObjectContextIml并添加了InRequestScope选项。

InRequestScope适用于 ASP.NET Web 应用程序，这意味着您的上下文应该为每个请求创建一次。Ninject 有几个不同的对象作用域，你可以使用它们来配置你的对象应该如何被创建和共享。

这样，您就可以完全控制对象的创建方式。

于 2013-04-02T08:11:47.143 回答