多年来我一直是.net网络开发人员(之前是PHP和asp经典),通常在开发应用程序时,我回避使用内置的.net sqlMembershipProvider主要是因为它经常看起来非常复杂,因为我的需求,其次是因为我只能想象这样一个复杂的数据模型可能会受到性能影响.
通常,我使用在相当简单的用户上操作的自定义成员资格和角色提供程序 – >用户角色< - 角色类型架构.我维护标准的成员资格提供程序功能,例如帐户恢复,配置文件详细信息,失败的登录帐户锁定,机密问题等,具体取决于相关应用程序的需求,例如AD安全应用程序几乎没有其他功能,面向公众的应用程序通常会有商场.它还意味着,如果出现任何需要存储过程来咀嚼用户数据的任务,那么它们很容易编写并且执行得非常好.直接的sql命令,良好的索引和简单的数据模型,产生了一个高性能,可扩展的解决方案,需要改变我有完全的控制权,可以根据需要进行更改,这是我认为非常宝贵的. 根据您的经验,您会说这是一种过时的方法吗？您是否曾在内置提供程序中遇到任何可伸缩性问题？您通常采取什么方法以及在什么情况下？ 谢谢
解决方法
我们发现内置的提供商为我们提供了所有基础知识,而我们几乎没有任何工作.开发一个良好的安全结构有很多元素,很容易忘记其中一个,或者只是为了变得懒惰,而不是在你自己滚动时以“正确”的方式实现一个.我想到了通过电子邮件密码和密码重置等问题.
当然,sqlMembershipProvider并不是神奇的子弹.我们有一些情况需要做一些更复杂的身份验证.但我们只能通过扩展sqlMembershipProvider而不是替换它来解决这些问题.有关详细信息,请参阅What is a good way to extend .Net Membership to track user logins的答案.
我们没有注意到sqlMembershipProvider产生的任何重大性能问题,所以我认为播放性能卡是没有根据的.毕竟,您的用户通常花多少时间登录系统？如果您的所有页面加载速度很快,那么根据您可能会提高性能的(可能是错误的)想法编写所有自己的代码并没有真正的理由.这是我们一直在阅读的可怕的“过早优化”.
角色框架对我们的需求来说太简单了,所以我们根本不使用它.但它也没有妨碍.
而且,正如Hogan指出的那样,你更有可能找到已经熟悉内置提供程序工作方式的开发人员,这意味着他们将花费更少的时间来弄清楚你的架构和(希望)更多的时间完成真正的工作.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
