自定义会员资格提供商和领域驱动设计
我担心我在哪里编写自定义会员资格提供程序，但我不确定将其放在哪里。我实际上没有任何代码可以向您展示，但基本上提供程序需要访问 System.Web.Security 才能继承该类，但它也需要数据访问（即连接字符串 + LINQ to SQL）来执行简单的操作诸如验证用户之类的任务。
如何编写一个符合我在 Apress 的 Pro ASP.NET MVC2 Framework 中读到的 DDD 原则的成员资格提供程序？我的一个想法是在我的领域项目中编写另一个类，它完成与数据库相关的所有“工作”。本质上我的方法数量会增加一倍。另外，这可以与依赖注入（IoC）一起使用吗？
希望这不是太笼统……
期待蜂巢思维的回应！
编辑：我刚刚注意到在默认的 MVC2 项目中有一个 AccountController，它有一个 IMembershipService 的包装器。这就是我的答案吗？ AccountController 似乎没有数据库访问组件。
I have a concern where I am writing a custom membership provider, but I'm not sure where to put it. I don't really have any code to show you, but basically the provider needs access to System.Web.Security in order to inherit the class, but it also needs data access (i.e. a connection string + LINQ to SQL) to do simple tasks such as ValidateUser.
How can I write a membership provider that adheres to the principles of DDD that I've read about in Pro ASP.NET MVC2 Framework by Apress? My one thought was to write another class in my domain project which does all the "work" related to database stuff. In essence I would have double the number of methods. Also, can this work with dependency injection (IoC)?
Hope this isn't too general ...
Look forward to the hive-mind's responses!
Edit: I just noticed in a default MVC2 project there is an AccountController which has a wrapper around an IMembershipService. Is this where my answer lies? The AccountController seems to have no database access component to it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Asp.net 用户管理功能具有超级侵入性。
他们甚至用配置文件表之类的垃圾邮件数据库。
当我必须对我的应用程序实施用户管理时，我成功地避免了所有这些混乱，并且仍然能够使用 ASP.NET 内置角色、用户身份等。尽管因为我的域变得足够智能来决定，但远离所有这些可以看到和执行的内容，因此在 UI 客户端中重复这些内容是没有意义的。
所以...是的。 这个仍然有零问题方法。大约 4 个月没有改变任何东西。
就像魅力一样。
Asp.net user management features are super invasive.
They even spam database with profile tables and what not.
When I had to implement users management of my application, I successfully avoided all that mess and still was able to use asp.net in-built roles, user identities etc. Moving away from all that though cause my domain is getting smart enough to decide what can be seen and done so it makes no sense to duplicate that in UI client.
So... yeah. Still have zero problems with this approach. Haven't changed anything for ~4 months.
Works like a charm.