0

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

控制器或业务层：

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

或者

在 DataLayer 中执行此操作：

SaveObject(Object)
{ 

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

}
4

3 回答 3

2

Whilst this is indeed a cross-cutting concern, my personal preference is that code such as:

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

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.

于 2009-02-07T15:55:39.100 回答
2

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)

于 2009-02-07T16:08:34.427 回答
1

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.

于 2009-02-07T15:30:22.803 回答