安全评估的适当地点.业务逻辑或数据访问

Question

对不起，here...hopefully，我没有过火.

我正在开发我的第一个MVC应用程序，并试图在这个过程中坚持DDD原则。我遇到了一些与如何处理应用程序的安全需求有关的问题，我想看看SO社区是否可以提供一些最佳实践建议。

域信息

为了使用简化的解释，这个应用程序将有AffiliateCompanies、Users和Customers。

• AffiliateCompanies是分层的，因此一个附属机构可以注册并绑定到另一个附属机构的活动中。根是提供产品/服务的主要公司。
• Users都属于一个附属实体。
• Customers是向其出售产品/服务的组织。附属公司被分配给客户，这样就有可能有两个层次化的分支机构--不相关的分支机构分裂一个客户。

安全信息

在应用程序中执行某些操作的权利将根据ACL类型的安排来确定。每个User对象都有一个属性，它是SystemAccessRules的集合，用于确定它们可以执行哪些操作以及权限的范围(它们自己的对象、其附属对象或其整个层次结构的对象)。用户也可以属于角色，角色本身拥有相同的SystemAccessRules集合。

因此，如果用户登录并希望看到“他们的”客户列表，则该列表可以由他们被单独分配给的客户、其附属组织中的任何人被分配给的客户、或其组织中的任何人或他们的任何子附属组织被分配给的客户组成。

数据库注意事项

撇开DDD不说，在某种程度上，存储策略必须发挥作用。在这个简单的场景中，表与上面的对象(包括一个角色表)保持一致，并有几个支持表来支持对象之间的关系：

• AffiliateCustomers -此表允许子公司和客户之间的多到多关系，方法是将每个实体的PK存储为一对FKs，它们本身就是该表的复合PK。
• ACL -此表存储安全信息，特别是条目的主题(用户或角色)、所涉及的操作(例如：( "CreateCustomer")、权限(允许或拒绝)和范围(他们自己的东西、他们的组织的或者他们的网络的)。

Question...Finally

我使用的是存储库和服务的组合。我试图将业务逻辑保留在服务和存储库或数据库之外，但是由于这里的安全设计，对“他们的”客户列表的一个简单请求可能会带来极大的负担，尤其是随着数据集的增长。我试图在可能的情况下使用Linq，但是这个体系结构似乎不太适合。在我看来，这是我的选择：

1. 接受请求用户作为服务方法的参数(或根据上下文确定它)，并让服务方法通过多个查询填充到Linq存储库中的列表。这将需要提取客户列表，然后遍历每个客户以发出另一个查询以提取ACL数据，然后使用该数据根据权限筛选第一个列表。如果可能的话，层次结构问题需要一些花哨的Linq步法(如这)。 即使等级问题可以发挥作用，这个解决方案似乎也不会有很好的效果。
2. 接受请求用户作为参数，但传递它和所需的权限。(“查看客户”)到存储库，以便通过存储过程从数据库中检索适当的数据，该存储过程将使用CTE查询中的多个存在子句，这些子句可以解释数据的分层性质以及检查角色和用户安全性的需要。 这给数据库带来了相当多的逻辑，这似乎是非常反DDD的，而且通常都很糟糕。

我更倾向于第二种选择，但这可能是因为在我过去的项目中，我就是这样做的。我甚至不确定我的设计总体上是否正确(在过去，权限声明是使用位标志完成的，所以使用按位运算符进行DB查询就更容易了)。

有没有人在类似的情况下，如果是的话，你能评论一下你所追求的解决方案的性能和可维护性吗？我想坚持高尚的编程原则，但不要以简单和常识为代价。

Answer 1

您考虑过使用规格模式将业务规则向下传递到数据访问层吗？

该服务构造一个规范树，并将其传递给存储库。存储库将规范转换为Expression<Func<Customer, bool>>，并将其传递给IQueryable<Customer>.Where(...)。当存储库将集合具体化时，例如通过调用ToList()，业务规则将被转换为SQL并在数据库服务器上执行。

上一次我检查时，LINQ不支持CTE，因此您可能需要使用视图来平缓层次结构。