0

我正在尝试设计一个 3 层的应用程序：

1) 数据访问层
2) 业务层
3) UI

我尝试保持类解耦，因此在业务层上我为数据访问类创建了接口，如下所示：

public interface ICountryRepository:IRepository 
{
    Country  GetCountry(int ID);

    int CreateCountry(Country obj);
    Boolean UpdateCountry(Country obj);
    Boolean DeleteCountry(Country obj);
    ...
    ...
 }

我将接口作为参数传递给服务构造函数：

   public CountryService(ICountryRepository repository,ILanguageRepository lang_repository)
   {       
    ....
   }

但是例如在 CountryService 上，我需要加载当前用户及其权限，以便检查是否可以应用该操作：

    public Country GetCountry(int ID)
    {

        if securityService.UserHasPermission(currentUser, GetPermission("CanGetCountry"))
        {
           return repository.GetCountry(ID);
        }
        else
        { 
           Throw(New SecurityException("No permissions for that operation ...."))
        }

    }

这意味着我必须实例化 SecurityDataAccess 对象并将其传递给我的业务层程序集上的 SecurityService 的构造函数，我试图避免这样做以保持对象解耦。现在我什至没有在我的业务程序集中引用任何 DataAccess 程序集。

我正在考虑在这里使用 IoC 容器。使用外部配置，我可以从配置文件中获得正确的类/程序集。但我不确定这是否是正确的解决方案，因为据说 IoC 容器应该在一个地方使用以保持简单，并且大多数时候它应该是顶级程序集（UI 程序集）。

有人有解决这个问题的建议吗？

4

3 回答 3

1

为什么不将安全服务添加到 Country 服务的构造函数中？这样，IOC 容器可以解决依赖关系并在需要时注入安全性。这意味着 IOC Container 将负责构建您的 CountryService 对象。您将使用容器来获取所有服务。

另一种选择可能是稍微“规范化”您的存储库......

修剪到它只有 4-5 个对所有存储库都相同的基本功能，然后使用泛型使它们看起来都一样，所以没有

UpdateCountry(...) 但更新(T 对象)

像这样的东西： http: //codebetter.com/blogs/gregyoung/archive/2009/01/16/ddd-the-generic-repository.aspx

然后您可以使用责任链模式将您的安全代码放在数据库代码之前（http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern）

因此，您可以拥有一个 SecurityChecker 来验证访问，如果无效则抛出异常，或者在链中的下一个链接中传递请求（您也可以通过这种方式动态添加日志记录，或计时或其他方式）

于 2009-09-12T07:59:53.737 回答
0

您是否需要在数据访问层实现安全性？如果您按照 Heiko 的建议将安全服务移至业务层。换句话说，在业务层执行安全性，就可以完全避免 IoC 问题。

于 2009-09-12T12:17:39.073 回答
0

这可能是离谱的，如果是，请道歉，我是一个潜伏的 Java EE 程序员。在我看来，授权是在基础设施中以声明方式更好地解决方法的方法。

这篇文章似乎暗示 .Net 像 Java EE 一样提供了一种以声明方式控制访问的工具。这种方法对你有用吗？

于 2009-09-13T21:18:35.020 回答