2011-01-24 50 views
1

让我们想象一下下面的轮廓(我假设我们使用ASP.NET MVC,但它并没有多大的这个问题)如何禁止存储库使用?

  1. 我们有直接从控制器使用存储库

  2. 一些存储库方法需要以某种特定方式处理,组合,缓存等。因此,我们为这些情况创建服务。所以现在应该从服务中访问一些存储库方法,但不是直接访问。控制存储库方法的方法是从正确的地方使用的?

我看到下面的方法:

不要使用存储库,直接在所有 - 使用它们只能从服务(我们甚至可能使仓库内,仅可见服务组装)。但是在这种情况下,我们必须创建仓库方法的包装,甚至可以直接使用仓库中的方法。

但我敢肯定有更有趣的,美丽和实现它灵活的方式...

回答

3

我见过的一般最佳实践的建议是,如果你需要它有时总是使用一个服务层。这样你就习惯了使用它,并且在你应该使用它时不会错误地绕过它。

但是,这不是我在我的应用程序中做的非常类似的情况。在我们的应用程序中,我们有DAL(数据访问层)类和BAL *业务访问层)类。但是,绝大多数呼叫不需要任何业务规则。在25个DAL中,我们只需要3个BAL。所以剩下的22个BAL只是直接的门面/代理类。

所以为了解决这个问题,我们定义了一个我们所有的DAL/BAL类实现的接口(每种类型一个接口)。因此,对于UserDal和UserBal都实现IUser(或者UserBal可能完全丢失,实际上对于用户而言)。

然后我们使用反射来实现以下方法:

BalFactory.GetClass<IUser>() 

这将寻找IUSER在BAL命名空间的实现,如果它没有找到一个,它返回从该执行IUSER DAL命名空间。然后,如果我们以后需要在最初没有添加BAL类时添加BAL类,那么我们只需将它添加到具有适当界面的BAL名称空间中,并且它会自动拾取并使用。

我们在大约四年前开始在应用程序中使用这种反射,我们对此非常满意。今天,我认为MEF可以更轻松地做到这一点。

+0

谢谢你分享你的经验!缺乏“始终使用服务”的建议是,在任何时候都可能出现另一个服务层:) – SiberianGuy

+0

(+1)这个主题有很多灰色区域,我喜欢这个概念。 – used2could

相关问题