我是MVC框架的新手,刚刚运行了NerdDinner示例项目。我喜欢这种方法而不是基于表单的asp.net。
我想使用同样的方法来调整一个更大的副项目。您是否看到该项目中的任何内容会阻止我将基本结构扩展为更复杂的网站?
让我警惕的事情的例子: 1)NerdDinner示例访问只有两个表的数据库,我的数据库大约有30个。 2)NerdDinner项目直接使用LinqToSQL类......从模型,控制器到视图的所有方式......对于更大的项目来说是犹太教的吗?
您是否看到NerdDinner框架的任何其他部分可能会导致我未来的悲痛?
答案 0 :(得分:2)
我同意其他人认为模型应该是你使用linq2sql的唯一地方,我的小附录只是在小项目的模型中使用linq2sql。对于较大的站点,创建一个单独的Web服务项目可能需要额外的开销,该项目可以与数据库进行所有通信并利用模型中的Web服务。
我从未完全检查过Nerd Diner示例,但其他最佳实践包括Typed Views和使用允许轻松验证的数据模型器(请参阅xval或DataAnnotations模型绑定器)。对我来说,这些是最重要的两个最佳实践/
Stephen Walter在他的website上有很多很好的提示,值得一试,并在设立新的MVC项目时予以考虑。
答案 1 :(得分:1)
当谈到Linq to Sql类时,互联网上有很多争论。有些人认为,当你直接使用这些类时,抽象是不够的,有些人认为这就是他们所需要的。在工作中我们开始改造我们的网站,我们正在使用MVC。我们决定采用的方式基本上是每个LINQ to SQL类都实现了一个接口。 IE:
public partial class LinqToSqlClass //generated class
{
public int Id{get;set;}
}
interface ILinqToSqlClass
{
int Id{get;set;}
}
public partial class LinqToSqlClass : ILinqToSqlClass
{
}
这只是其中的一小部分。然后我们有一个存储库,可以获取这些生成的类中的任何一个,但只能作为它们的接口类型。这样,我们永远不会直接使用Linq to Sql类。有许多不同的方法可以做到这一点,但通常我会说是的,如果你正在处理一个大型数据库(特别是如果模式可能会改变)或者你正在处理可能来自多个来源的数据,绝对不要直接使用这些类。
最重要的是,在Nerd Dinner章节中有很多好消息,但是在创建自己的项目时,你显然会遇到自己的问题,所以请随时随地使用。
答案 2 :(得分:1)
我会在存储库和控制器之间添加一个服务层。服务层将包含您的所有业务逻辑,让您的控制器主要处理表单输入和页面流。
在存储库中,我将LinqToSql类和字段映射到域模型,然后使用服务层,控制器和视图中的域模型。对于更大的系统,从长远来看,额外的层将证明它们的价值。
答案 3 :(得分:0)
Nerd Dinner文本声称MVC框架同样可以很好地适应其他常见的数据抽象。 (这是真的。)听起来你的组织已经拥有它喜欢的一个。一个好的学习策略可能是让一个人适应另一个。