我有一个由3层组成的应用程序:
UI :在ASP.NET MVC中实现
业务:保持业务逻辑和资源访问控制
存储库(DAL):使用存储库模式使用POCO对象和EF实现。我的POCO对象与上层共享。
我对POCO应该有哪些信息/方法有疑问? 即:如果我有一个用户表,其中包含用户的用户名和密码,我的POCO应该有什么?我该如何验证密码?我的POCO应该有一个方法要求存储库进行验证吗?
另外,我应该如何控制对资源的访问?我的存储库是否可以控制谁可以访问资源?这仍然允许我的POCO使用导航属性公开信息。如果当前用户也可以使用它,我应该检查POCO propoertise吗?
提前致谢。
答案 0 :(得分:1)
我有一个类似的项目,我可以给你一些关于我如何执行类似操作的细节。我假设您的整个解决方案都是基于.Net的。
POCO(普通旧CLR对象)就是那些没有业务逻辑的对象。因此,密码验证不应直接在该类中,而应在您的业务层中。例如,UI会调用控制器操作将数据提交到业务层(BL),BL将通过调用存储库来获取当前存储/加密的密码来执行用户密码验证,BL将比较密码并返回结果到您的用户界面或采取其他一些行动。当然,所有数据也应该经过验证,以防止SQL注入或跨站点脚本攻击等事件。
您的POCO可以拥有Uid / Pwd属性。您应该在应用程序层之间传递此POCO对象。因此,MVC UI将绑定到您的用户对象,并且在提交时,控制器将调用BL中的某个方法,并对该用户对象执行业务规则(密码有效)。为了在实际层之间传递这些,您需要从主DAL中提取这些POCO并将它们放在单独的程序集中。这些对象通常称为域对象,您可以通过谷歌域驱动开发来获取有关该方法的更多信息。
安全性可以在应用程序中以多种不同的方式实现,这一切都取决于您想要涵盖的项目的深度。 MVC中最基本的是在控制器类上使用Authorize属性(google:Securing Your Controller Actions)。对您的用户进行身份验证后,可以为他们分配某种类型的应用程序角色,您可以使用以下格式验证用户是否具有这些角色之一:
[Authorize(Roles = "ModifyUserRoles")]
public ActionResult About()
{
}
答案 1 :(得分:0)
如果您的上下文返回用户对象,则select将“验证”密码:
public User GetUser(string login, string password)
{
//...code to set up context var...
var user = (from o in context.Users.OfType<User>() where o.UserID == login && o.Password == password) select o).FirstOrDefault();
//...maybe more code...
}
应该由您的业务层决定如何加密密码以及如何处理失败的登录(方法返回null)。
就个人而言,我认为任何业务逻辑都不应该在您的DAL中。确定谁有权访问业务层最佳执行的功能但您可以禁用延迟加载并仅包含基于用户的导航属性,或者您可以在需要时对这些属性进行额外请求。返回的数据量和类型(出于性能原因)将推动该决定。
答案 2 :(得分:0)
我认为并不总是需要通过图层传递你的POCO对象(域对象),例如在你的情况下,View层只需要一个只有用户名和密码属性的简单View Model并将它传递给BL ,你的BL将通过存储库获取用户域对象,并根据从View层收到的内容验证密码。