28

我目前正在将一个非常古老但可以正常工作的经典 ASP 站点转换为 ASP.Net。

它有一个完全定制的书面用户管理系统。虽然它运行良好，但它确实需要更新，因为我希望它对未来的一些项目更加灵活。

当我问别人这个问题时，他们说“你需要使用 Microsoft Provider”，并就微软如何免费发布所有这些东西以及它们有多好并且应该尽可能地重复使用进行了演讲。

我已经对它进行了相当多的研究（主要是看http://asp.net/learn上的视频），并且对其中的一些功能印象深刻，因为似乎有拖放组件用于需要的项目我的年龄来写。

但是，目前的会员数据库解释起来很复杂，它是一个完全自定义编写的数据库，内部关系很多……它与默认的 Microsoft Provider 并不真正“兼容”。

我查看了如何：创建自定义成员资格提供程序？，但我觉得有点脱离了我的舒适区，担心它要么会很慢，要么会引入安全漏洞，要么根本不起作用。

归根结底，Microsoft Membership Provider 应该为我工作 - 我真正需要的唯一自定义是登录以使用我的数据库中的用户名/密码字段和创建用户脚本，其中包含很多自定义代码到三分之一政党系统（需要提供服务等）。

我只是想知道，如果遇到类似的情况，你会怎么做？

  1. 使用 Microsoft Membership Provider 并以某种方式让它为您工作（尽管我想要建议）

  2. 使用 Microsoft Membership Provider，但使用围绕您的代码自定义的自定义提供程序。

  3. 使用您自己的完全定制的解决方案？

4

4 回答 4

8

我过去也遇到过类似的情况。在这两种情况下，我们都围绕现有机制创建了提供程序（MembershipProvider、RoleProvider、ProfileProvider）的自定义实现。

在这两种情况下，我们只使用提供者实现进行只读访问，例如在 web.config 等中为我们提供简单的验证 gubbins。用户管理代码被单独留下，因为它工作得很好。

于 2009-12-04T10:53:01.400 回答
8

该视频确实使事情复杂化:)如果您要实现自定义提供程序，那么现有提供程序的反射器是一个不错的起点:)

当然，作为一种快速而肮脏的选择，您可以破解 SQL 成员资格提供程序使用的存储过程，但用于提供服务的自定义代码可能会扩展它。

如果您考虑一下，服务的远程配置并不真正属于会员提供者，它并不是真正的会员功能 - 所有会员所做的只是提供用户名和密码以及围绕它们的身份验证。我自己的感觉是，您应该将服务的供应移出那里，并在创建用户后在 ASP.NET 站点上执行它——即使这只是在成员资格提供者完成它的事情后调用存储过程。如果您这样做，您可能会发现 SQL 成员资格提供程序将完成您需要它做的所有事情（可能也使用角色和配置文件提供程序），因此您可以编写更少的代码！

于 2009-12-04T11:07:52.557 回答
3

如果现有提供程序有效（为您的数据提供正确的字段），请使用它开始。稍后您可以很容易地用客户提供商替换它（只需更改单个配置值）。

请注意，没有“开箱即用”的 ASP.NET 管理界面，您需要自行开发或使用第三方管理界面。

于 2009-12-02T18:32:44.023 回答
3

使用我专门的 MembershipProvider 来处理我自己的数据库表。

于 2009-12-04T11:10:59.430 回答