具有 Web 界面和 DAL 的自定义 MembershipProvider
我正在开发一个包含 2 个项目的 ASP.NET 解决方案。一个是网络界面，另一个包含我的业务逻辑。我在第二个项目中使用 LINQ to SQL 进行数据访问。
除了数据库之外，我还有一个名为“用户”的表，其中保存用户信息。
我已经开始实现 MembershipProvider。我注意到 MembershipUser 与 MembershipProvider 耦合在一起。让我的 BLL/DAL 谈论用户的最正确方法是什么？ 我应该至少实现 MembershipUser 并且每当用户调用方法时，它都会调用例如。我的 BLL/DAL 中的 GetUserInfo() 来获取有关用户的完整信息？
或者我应该让 MembershipUser 类方法调用 BLL/DAL 中的自定义“Users”类方法（如包装器）（此自定义用户类与 linq 无关）？
或者我可以以某种方式扩展 Linq to sql 类“CFUsers”来扩展 MembershipUser。
我希望这是有道理的。
I'm working on an ASP.NET solution with 2 projects. One is the web interface and the other contains my business logic. I'm using LINQ to SQL for my data access in the second project.
Apart of my database, I have a table called Users which holds user information.
I've started to implement a MembershipProvider. I notice that MembershipUser is coupled with MembershipProvider. What is the most correct way of getting my BLL/DAL to talk about Users?
Should I minimally implement MembershipUser and whenever a user calls a method, it will call for eg. GetUserInfo() in my BLL/DAL, to get complete information about the user?
Or should I make the MembershipUser class methods call my custom "Users" class methods (like a wrapper) in the BLL/DAL (this custom users class is not related to linq)?
Or can I somehow extend the Linq to sql class "CFUsers" to extend MembershipUser.
I hope this makes sense.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我通常认为这是一个单独的实体，因为 MembershipUser 围绕成员资格，这是一个普遍关注的问题，而您系统中的用户则围绕您的域所涉及的任何内容，我确实看到您的观点，即这两个实体可以包含在一个实体中，所以。配置文件绝对是最简单的方法。
MSDN 文档上有一个演练：
http://msdn2.microsoft.com /en-us/lib...US,VS.80).aspx 和
Scott Guthrie 提供的很好的演练，位于
http://weblogs.asp.net/scottgu/archi。 ..18/427754.aspx
一如既往，这取决于您的目标是什么。添加到配置文件是一个简单的机制
获取更多数据。它需要很少的定制和
使信息可以轻松地供 Web 应用程序使用。这可能不是
您想要存储此类数据的位置；如果不是，那就是非解决方案。
如果这不适合，则创建一个从默认提供程序派生的新提供程序（以
继承你已有的）是一个不错的选择。
当然还有终极 http:// codesmart.wordpress.com/2009/03/27/extending-the-microsoft-aspnet-membership-provider/
I usually see this a seperate entities as MembershipUser revolves around membership which is a generic concern and a user in your system revolves around whatever your domain entails, I do see your point of view where both these entities could be contained in one, so. Profiles is definitely the easiest way to go.
There's a walkthough on the MSDN docs at
http://msdn2.microsoft.com/en-us/lib...US,VS.80).aspx and a
good walkthrough from Scott Guthrie at
http://weblogs.asp.net/scottgu/archi...18/427754.aspx
As always It depends on what your goals are. Adding to Profile is a simple mechanism
for additional data. It requires very little in the way of customization and
makes the info easily available for the web application. This may not be
where you want to store this type of data; if not, it is a non-solution.
If this does not fit, making a new provider derived from the default (to
inherit what you already have) is a great option.
and of course the ultimate http://codesmart.wordpress.com/2009/03/27/extending-the-microsoft-aspnet-membership-provider/