我正在创建我的第一个ASP.NET MVC站点,并一直在尝试遵循域驱动的开发.我的站点是一个项目协作站点,可以将用户分配到站点上的一个或多个项目.然后将任务添加到项目中,并将项目中的用户分配给任务.所以"用户"是我的域模型的基本概念.
我的计划是拥有一个"用户"模型对象,其中包含有关用户的所有信息,可以通过IUserRepository访问.UserId可以识别每个用户.虽然我现在还不确定我是否希望UserId是一个字符串或整数.
我的域对象User和IUserRepository应该如何与我的网站的更多管理功能相关,例如授权用户并允许他们登录？如何将我的域模型与ASP.NET的其他方面集成,例如HttpContext.User,HttpContext.Profile,自定义MemberShipProvider,自定义ProfileProvider或自定义AuthorizeAttribute？
我应该创建一个自定义MembershipProvider和/或包含我的IUserRepository的ProfileProvider吗？虽然,我也可以预见为什么我可能想要将我的域模型中的用户信息与我站点上的用户授权分开.例如,将来我可能希望从表单身份验证切换到Windows身份验证.
不尝试重新发明轮子并坚持使用ASP.NET内置的标准SqlMembershipProvider会更好吗？每个用户的个人资料信息都将存储在域模型(User/IUserRepository)中,但这不包括他们的密码.然后我会使用标准的ASP.NET成员资格来处理创建和授权用户？因此,在创建帐户或第一次登录时,需要在某个地方创建一些代码,以便为IUserRepository中的新用户创建配置文件.
假设您要开发一个系统,实体和域逻辑的可用性高度依赖于用户上下文.通过使各个存储库实例用户上下文感知来处理存储库中的用户上下文敏感性是否有意义？我正在考虑采用这种方法作为一种方式来消除对我的实体的依赖用户背景,但我不确定是否有任何陷阱,我可能不会意识到这个方向.我计划首先接近这个的方法是将UserContext参数添加到需要此上下文信息的存储库的构造函数中.另一个明显的选择是将用户上下文信息提供给我的存储库中的每个查询方法,但这可能意味着大多数方法都需要这样的参数,这反过来会大大增加每个方法调用的详细程度.
此外,我想指出,我知道即使我要使存储库用户上下文意识到,当服务或实体需要相同的用户上下文信息时,这不一定有助于确定基于用户的行为等原因组态.我也对这些案例的其他解决方案感兴趣但是现在我试图一次解决一件事,所以我首先关注的是存储库.
任何建议,将不胜感激.
我们的团队决定将Domain Driven Design架构用于我们的项目.现在正在进行讨论," 我们可以在DDD中使用ASP.NET身份吗？".
在DDD设计中使用ASP.NET标识是否有任何缺点.
我很困惑,要做出决定.
我已经搜索过了,但我没有想到.
任何帮助都会很明显.
我似乎错过了一些东西,谷歌的广泛使用无助于提高我的理解......
这是我的问题:
我喜欢以持久性无知的方式创建我的域模型,例如:
virtual如果我不需要,我不想添加.对此的一个解决方案是具有单独的域对象和数据实体.使用存储库模式可以轻松地检索构造的域对象,并从ORM返回的数据实体构建域对象.使用AutoMapper,这将是微不足道的,而不是太多的代码开销.
但是这个方法有一个很大的问题:似乎我不能真正支持延迟加载而不自己编写代码.另外,对于相同的"事物",我会有很多类,特别是在WCF和UI的扩展上下文中:
所以,我的问题是:我错过了什么？这个问题一般如何解决？
更新:
到目前为止的答案表明我已经担心的事情:看起来我有两个选择:
更新:
除了接受的答案,请参阅我的答案,了解我如何为我解决这些问题的具体信息.
我正在构建一个MVC 3应用程序,需要找到一个管理身份验证和授权的好解决方案.我使用过Membership,在这种情况下我不想使用它 - 我更喜欢使用自己的设计和表格.但是,如果合适的话,我愿意使用内置接口实现我的自定义逻辑.
这是我的要求:
用户可以是一个或多个角色的一部分.
角色可以映射到任意数量的"权限"(多对多).权限类似于"可以编辑其他用户的帖子".
每个控制器动作可以允许访问一个或多个角色(或者对于公共页面可以不需要授权).
我还需要"功能级别"控制哪些角色可以查看/更新视图上的各种元素.可以使用权限来驱动这些角色.
作为旁注,我可能还允许会员使用他们的Facebook和/或Twitter帐户进行注册.但这可以独立于我的自定义成员身份实现,如果这是合适的(即在注册时创建自定义用户,然后将其绑定到FB/Twitter帐户).
我确定之前有人做过这样的事情.但基于我在这个主题上看到的十几个博客和SO帖子,没有一个解决方案真的适合这个,它似乎并不存在.但是我很有可能无法将各个部分组合在一起,并且适当的东西正在盯着我.
例如,我已经阅读了一些关于"基于声明"的身份验证与"基于角色"的身份验证,但不确定我是否了解足够的差异来进行呼叫,也不确定天气是否需要ASP.NET成员身份.我还读到了通过实现IPrincipal和IIdentity以及使用动作过滤器来驱动控制器访问来构建自定义成员资格,但我没有找到任何全面的指南来实现这一点,而且我仍然相当绿色的动作过滤器.
我也不确定是否应该使用一些.NET的内置控件进行注册,身份验证,忘记密码等等.我的本能不是,因为我通常喜欢自己构建这些,我也不确定如果他们可以在自定义设置中工作.但如果我错了,请告诉我.
提前致谢.