Question

当userID不是传递的对象中的字段，但在提交数据时仍需要使用userID交叉引用表时，如果将数据提交到数据层，我应该调用成员资格类来获取数据层中的UserID，或者我应该将UserID从一个级别传递给另一个级别作为参数？（即从业务层到数据层？）（或者两种方式无关紧要？）

控制器或业务层：

 MembershipUser user = Membership.GetUser();
 Guid userID = (Guid)user.ProviderUserKey;
 DL.SaveObject (Object, userID);

OR

在DataLayer中执行：

SaveObject(Object)
{ 

 MembershipUser user = Membership.GetUser();
                Guid userID = (Guid)user.ProviderUserKey;
 ...
 ...

}

Answer 1

虽然这确实是一个贯穿各领域的问题，但我个人的偏好是代码如：

MembershipUser user = Membership.GetUser();
Guid userID = (Guid)user.ProviderUserKey;

不应该在数据层中。

我喜欢在高于数据层（通常是业务层）的层中看到这种代码，因为我希望我的数据层完全不可知，因为它将读取/写入/处理的数据来自。我希望我的数据收集主要在UI层（在用户提供的数据/输入的情况下）完成，并且可能在业务层内收集更多的数据（例如收集UserID或检索用户的角色/授权）。

将此类代码放在业务层中可能会导致此代码跨越许多不同的域对象重复，但是，这可以通过将此代码抽象到其自己的对象中，并使用对象组合来允许其他域来缓解要访问它的对象。

Answer 2

将输入传递给DataAccessLayer应该由控制器或BL完成。我不想在DAL中包含除数据读/写之外的任何内容。（在这种情况下，DAL被赋予确定当前登录用户的任务）

Answer 3

一般来说，我更喜欢在SaveObject（）中看到GetUser（），因为这样可以将业务层从中抽象出来，并且应该减少调用GetUser（）的代码量。但这取决于要求。如果您需要根据用户的身份应用业务规则，那么（也）将其放在业务层可能更有意义。

授权/身份验证是AOP（面向方面编程）最适合处理的跨领域问题之一。

<强>更新 CraigTP提出了一个有效的观点，即数据层与数据的来源无关。总的来说，我同意。在这种情况下，存在数据持久性机制需要用户身份的要求，可能出于安全和/或审计目的。所以在这种情况下，我更愿意将用户身份访问调用置于需要它的层的控制之下。我将抽象出另一个调用后面的GetUser（）实现的细节，因此数据层不依赖于System.Web.Security。

我应该在应用程序级别之间传递UserID吗？

3 个答案: