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

当用户ID不是被传递对象中的字段时，将数据提交给数据层，但在提交数据时仍然需要用userID交叉引用表，我应该调用成员资格类来获取数据层的用户ID，或者我应该从级别传递UserID作为参数吗？（即从业务层到数据层？）（或者它不重要无论哪种方式？）我应该在应用程序级别之间传递用户ID吗？

控制器或业务层：

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

做到在数据层：

SaveObject(Object) 
{ 

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

}

来源

2009-02-07 zsharp

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

授权/认证是AOP（面向方面编程）最适合处理的一个交叉问题。

更新： CraigTP使得数据层不知道数据来自何处。总的来说，我会同意。在这种情况下，数据持久性机制需要用户身份，这可能出于安全性和/或审计目的。所以在这种情况下，我宁愿将用户身份访问呼叫置于需要它的图层的控制下。我会在另一个调用之后抽象出GetUser（）实现的细节，因此数据层没有对System.Web.Security的依赖。

来源

2009-02-07 15:30:22

虽然这确实是一个横切关注点，我个人的偏好是这样的代码：

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

不应该在数据层。

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

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

来源

2009-02-07 15:55:39 CraigTP

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

来源

2009-02-07 16:08:34 Ramesh

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

回答

相关问题