我应该在应用程序级别之间传递 UserID 吗？
当 userID 不是正在传递的对象中的字段时，将数据提交到数据层，但在提交数据时仍然需要使用 userID 交叉引用表，我应该调用成员资格类来获取数据层的 UserID，还是应该将 UserID 作为参数从一个级别传递到另一个级别？ （即从业务层到数据层？） （或者两者都不重要？）
控制器或业务层：
MembershipUser user = Membership.GetUser();
Guid userID = (Guid)user.ProviderUserKey;
DL.SaveObject (Object, userID);
或
在数据层中执行：
SaveObject(Object)
{
MembershipUser user = Membership.GetUser();
Guid userID = (Guid)user.ProviderUserKey;
...
...
}
WHen submitting data to Data Layer when userID is not a field in the object being passed, but will still need to cross reference tables with userID when submitting data, should I call the the membership class to get the UserID at the datalayer, or should I pass UserID from level to level as a parameter? (ie from the business layer to the data layer? )
(Or does it not matter either way?)
Controller or Business Layer:
MembershipUser user = Membership.GetUser();
Guid userID = (Guid)user.ProviderUserKey;
DL.SaveObject (Object, userID);
OR
Do it in DataLayer:
SaveObject(Object)
{
MembershipUser user = Membership.GetUser();
Guid userID = (Guid)user.ProviderUserKey;
...
...
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
虽然这确实是一个跨领域的问题，但我个人的偏好是，诸如以下的代码
不应位于数据层中。
我喜欢在比数据层（通常是业务层）更高的层中看到这种代码，只是因为我希望我的数据层完全不知道它将读取/写入/处理的数据来自何处。 我希望我的数据收集主要在 UI 层完成（在用户提供数据/输入的情况下），也许在业务层内收集更多数据（例如收集 UserID 或检索用户的角色/授权）。
将此类代码放入业务层可能会导致在许多不同的域对象之间重复此代码，但是，可以通过将此代码抽象到其自己的对象中并使用对象组合来允许其他域对象访问来缓解这种情况它。
Whilst this is indeed a cross-cutting concern, my personal preference is that code such as:
should NOT be in the data layer.
I like to see this kind of code in a layer higher than the data layer, usually the business layer, simply because I want my data layer to be entirely agnostic as where the data it will read/write/process has come from. I want my data gathering to be done primarily in the UI layer (in the case of user supplied data/input) and perhaps a little more data gathering within the business layer (such as gathering a UserID or retrieving a user's roles/authorisation).
Putting code such as this in the business layer can potentially lead to duplication of this code across many different domain objects, however, this can be alleviated by abstracting this code away into it's own object, and using object composition to allow other domain objects to access it.
将输入传递到 DataAccessLayer 应由控制器或 BL 完成。 我不想在 DAL 中包含除数据读/写以外的任何内容。 （在这种情况下，DAL被赋予确定当前登录用户的任务）
Passing input to the DataAccessLayer should be done by the controller or BL. I prefer not to include anything other than Data read / write in DAL. (in this case, DAL is given the task of determining the currently logged in user)
一般来说，我更喜欢在 SaveObject() 中看到 GetUser()，因为这将允许业务层从中抽象出来，并且应该减少调用 GetUser() 的代码量。 但这取决于要求。 如果您需要根据用户是谁应用业务规则，那么（也）将其放入业务层可能更有意义。
授权/身份验证是 AOP（面向方面编程）最适合处理的跨领域问题之一。
更新：
CraigTP 提出了一个有效的观点，即让数据层不知道其数据来自何处。 总的来说我会同意。 在这种情况下，数据持久性机制需要用户身份，可能是出于安全和/或审计目的。 因此，在这种情况下，我更愿意将用户身份访问调用置于需要它的层的控制之下。 我会抽象出另一个调用背后的 GetUser() 实现的细节，因此数据层不依赖于 System.Web.Security。
In general I'd prefer to see GetUser() in SaveObject(), since that would allow the business layer to be abstracted away from it and should reduce the amount of code that is calling GetUser(). But it depends on the requirements. If you needed to apply business rules based on who the user is, then (also) putting it in the business layer might make more sense.
Authorization/authentication is one of those cross-cutting concerns that AOP (aspect oriented programming) is best suited to handle.
Update:
CraigTP makes a valid point wrt having the data layer be agnostic about where its data comes from. In general I would agree. In this scenario there is a requirement where user identity is needed by the data persistence mechanism, probably for security and/or auditing purposes. So in this case I'd prefer to put the user identity access call under the control of the layer that needs it. I'd abstract away the details of the GetUser() implementation behind another call, so the data layer doesn't have a dependency on System.Web.Security.