帮助我决定是使用 ASP.NET 默认成员资格/角色提供程序还是编写自定义提供程序
昨天我花了很大一部分时间阅读这个主题，但仍然觉得我不确定该走哪条路。在身份验证和授权方面，我有“自己动手”的背景。我们从未使用过 Forms 身份验证，更不用说 Membership API。看看我们的旧代码，我们将使用会话变量来捕获/控制用户是否登录等。通过这个我即将进行的新项目，我想让我们回到我们应该做的事情的正轨，即就是使用框架提供的工具。
我已经有了一个将要使用的数据库模式，但它并不是一成不变的；如有必要，我可以对其进行更改。在此架构中已经有一个 Users 表，使用整数作为主键。该表还包含其他信息，例如名字和姓氏。我还有基于 UserId 的外键到其他表，例如电话和地址。下面我概述了我想到的一些优点/缺点。
默认提供程序
优点
- 代码较少。
- 能够利用所有关联的服务器控件，例如登录、更改密码。
缺点
- 有些控件开箱即用可能对我来说没有用。例如，CreateUserWizard，我可能需要在用户创建过程中捕获其他信息，例如关联表的电话和地址信息。不确定这是否会使该控件对我来说毫无用处。
- 我必须在关联表（电话、地址）中为 UserId 创建外键，UserId 是默认提供程序中的 GUID。
- 如果我确实创建了这些外键约束并且不使用级联删除；我还需要删除外键表中的关联行。可能必须利用 TransactionScope 对象之类的东西来确保所有这些都是原子操作。
自定义提供程序
优点
- 能够利用现有架构表。
- 更容易将身份验证/授权提取到服务中。
缺点
- 必须自己为大多数/所有事情提供实施。
- 要使用任何控件，我必须在提供程序中提供所需的实现。
可能还有其他事情我还没有考虑到，因为我以前从未使用过这个，这也让我有点不舒服。
谢谢。
I spent a good part of yesterday reading up on the subject and still feel like I am uncertain which way to go. I come from a "roll your own" background when it comes to authentication and authorization. We never used Forms authentication, let alone the Membership API. Looking at our old code we would use session variables to capture/control whether a user is logged in etc. With this new project I am about to undertake I want to put us back on track with what we should have done to begin with, which is use the tools provided by the framework.
I already have a database schema that I'll be working with, however it's not set in stone; I am able to make changes to it if necessary. In this schema there is already a Users table, utilizing an integer as the primary key. This table also has other information such as First and Last names. I also have foreign keys based on the UserId to other tables such as Phone and Address. Below I outline some of the pros/cons that come to mind.
Default Provider
Pros
- Less code.
- Ability to utilize all of the associated server controls such as Login, ChangePassword.
Cons
- Some controls might not be usedful to me out of the box. For example the CreateUserWizard, I will need to possibly capture other information during user creation such as phone and address information to associated tables. Not sure if this renders this control useless to me.
- I'll have to create foreign keys in my associated tables (Phone, Address) to the UserId which is a GUID in the default provider.
- If I do create these foreign key constrains and not utilize cascade delete; I will need to also delete associated rows in foreign key tables. Potentially having to utilize something like a TransactionScope object to make sure all of this is an atomic operation.
Custom Provider
Pros
- Ability to utilize existing schema tables.
- Easier to extract authentication/authorization into a service down the line.
Cons
- Have to provide implementation to most/everything myself.
- To use any of the controls, I'll have to provide their required implementation in the provider.
There might be other things I have not yet considered, being that I never used this before which makes me a little uncomfortable as well.
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
就我个人而言，我会选择框架提供的内容。在这种情况下，没有理由进行自己的身份验证。
过去，你可能想自己做事，但现在没有理由这样做。
我认为如果你尝试自己编写这个，你就会重新创造轮子，并且需要花费太多的时间和资源才能把它做好。尤其是在处理安全问题时。
Personally, I'd go with what the framework provides. There's no reason to roll your own authentication in this case.
In the past, you might have wanted to do things on your own, but nowadays there is no reason to.
I think if you tried to write this on your own, you'd be re-creating the wheel and it would take way too much time and resources to get it right. Especially, when dealing with security.
我最近不得不做出同样的选择，并决定创建一个自定义提供程序。
我这样做的最大原因归结为默认的数据库模式。所有默认的数据库对象都是在 dbo 模式中创建的，并以“aspnet_”或“vw_aspnet”等为前缀。对我来说，这是一个真正的关闭。如果您还没有看到它们，请运行 aspnet_regsql.exe 来创建它们。
另外，Steven Sanderson 在 Pro ASP.NET MVC 2 Framework 中这样说：
我还没有完成创建自定义提供程序的整个过程（我在使用 Azure 表存储时确实做了部分实现），但我计划将来在多个项目中使用这些提供程序，所以我觉得努力是值得的。
I recently had to make the same choice and decided to go with creating a custom provider.
My biggest reason to do this came down to the default db schema. All of the default db objects are created in the dbo schema and are prefixed with 'aspnet_' or 'vw_aspnet', etc. For me it was a real turnoff. If you haven't seen them yet, run aspnet_regsql.exe to create them.
In addition, Steven Sanderson says this in Pro ASP.NET MVC 2 Framework:
I haven't gone through the entire process of creating the custom providers yet (I did do a partial implementation when I was playing with Azure Table storage), but I plan to use these providers over multiple projects in the future, so I feel the effort will be well worth it.
如果您正在构建一个新的应用程序，我会毫不犹豫地使用 asp.net 默认提供程序。您始终可以决定不使用默认控件并以编程方式创建自己的控件。您还可以通过使用任何开源预创建的用户管理工具来节省大量时间。同时，您始终可以将包含的信息扩展到默认表中。
If you are building a new application I would not hesitate to use the asp.net default provider. you can always decide not to use the default controls and programatically create your own. you can also save a lot of time by using any opensource pre created user management tool. At the same time you can always extend the information contained into the default tables.
就我个人而言，我使用 SqlMembershipProvider 作为独立实体，而数据库的其余部分位于 Oracle 中。我从不查看数据库，因此名称和 GUID 不会打扰我（眼不见心不烦）。它开箱即用，太棒了！
在我的场景中，我在 Oracle 数据库中有一个用户表，在创建/删除成员资格用户时插入/删除该表（无 GUID）。我认为成员数据库是“主”记录，Oracle 表基本上是为了支持表的引用完整性。这并不是在正式事务中真正完成的，但我使用 try/catch 来保持它们足够好同步。
角色提供者确实很有限，如果您想要任何类型的分层或动态角色，那就太好了。但它是一个与会员资格完全隔离的独立系统，您不必使用它。
操控还不错。其中很多都支持模板，因此您可以向其中添加自己的控件，并有大量事件可以挂接到其中。不要害怕推出自己的控件，但首先要给默认控件一个机会。会员 API 的易用性确实有助于创建这些控件。
Personally, I use the SqlMembershipProvider as a standalone entity while the rest of my database is in Oracle. I never look at the database, so the names and GUIDs don't bother me (out of sight, out of mind). It just works out of the box, which is great!
In my scenario, I've got a user table in the Oracle database that I insert/delete when membership users are created/deleted (no GUIDs). I consider the membership database to be the "master" record and the Oracle table to be there basically for referential integrity of supporting tables. It's not really done in an official transaction, but I use try/catch to keep them synchronized well enough.
The Role Provider is really limited and if you want any sort of hierarchical or dynamic roles, you're toasted. But it's a separate system completely isolated from membership and you don't have to use it.
The controls aren't bad. A lot of them support templates, so that you can add your own controls to them, and have plenty of events to hook into them. Don't be afraid to roll your own controls, but give the default controls a chance first. The ease of use of the Membership API really facilitate creating those controls.