我正在开始学习一个新的ASP.NET MVC项目，并且想知道设置项目以连接到数据的SQL Server的最佳方法是什么。例如，假设我们有一个Product表和一个我想用来在视图中填充数据的product对象。

我知道在这里的某个地方我应该有一个已实现的接口，等等，但是今天我无法解决这个问题:-(

编辑：现在(即：该应用程序的当前版本，编码不正确)我只是使用普通的旧SQL Server(甚至2000)，仅使用存储过程进行数据访问，但是我不会对添加额外的层不利使用linq到sql的灵活性。

编辑＃2：我想添加的一件事是：我将针对数据库的V1编写此代码，并且我将需要让我们的DBA重做数据库并在以后给我一个V2，因此这样很好，因为只需要真正更改现在数据库中没有提供的一些小东西，这将在以后出现。无需重新编写全新的DAL。

解决方案

在我的站点的解决方案中，我有MVC Web应用程序项目和一个"公用"项目，其中包含我的POCO(纯Cobject)，业务管理器和数据访问层。

DAL类与SQL Server绑定在一起(我没有将它们抽象出来)，并将POCO返回给我从MVC项目中的控制器调用的业务管理器。

这实际上取决于我们使用的是哪种数据访问技术。如果我们使用的是Linq To Sql，则可能希望抽象化某种"存储库"接口(例如IProductRepository)背后的数据访问。这样做的主要吸引力在于，我们可以随时更改特定的数据访问实现(例如，编写单元测试时)。

我试图在这里介绍其中的一些内容：

我会查看Rob Conery在MVC店面创建方面的视频。该系列可以在这里找到：MVC Store Front Series

本系列探讨与设计相关的各种主题，以及与MVC和其他项目一起使用的编码/测试实践。

对于我们的应用程序，我计划使用LINQ to Entities，但是由于它对我来说是新的，所以如果将来它不能按我的意愿运行，我可能会希望替换它，并使用其他类似LINQ to SQL的方法或者NHibernate，所以我将把数据访问对象抽象到一个抽象工厂中，以便将实现隐藏在应用程序中。

只要我们选择一种行之有效且广为人知的设计模式来实施，这取决于我们，我认为最终产品将得到良好的支持和强大的功能。

请查看Code Camp服务器，以获得一个很好的参考应用程序，该应用程序可以执行此操作，正如@haacked指出的摘要所述，请务必将它们分开。

我认为Billy McCafferty的S＃arp体系结构是将ASP.NET MVC与数据访问层(默认情况下使用NHibernate)，依赖项注入(Ninject atm，但有计划支持CommonServiceLocator)和测试-驱动的发展。该框架仍在开发中，但我认为它非常好且稳定。从当前版本开始，在最终版本发布之前，几乎没有重大更改，因此可以对其进行编码。

使用LINQ。创建LINQ to SQL文件并拖放所需的所有表和视图。然后，当我们调用模型时，将自动为我们创建所有CRUD级别的东西。

LINQ是我很长一段时间以来见过的最好的东西。以下是一些简单的示例，这些示例可从Scott Gu的博客中获取数据。

LINQ教程

我刚刚完成了我的第一个MVC项目，并且使用了服务库设计模式。现在网上有很多关于它的信息。它使我轻松地从Linq-> Sql过渡到Entity Framework。如果我们认为将要进行很多更改，请付出一些额外的努力来使用接口。

我建议DAL /存储库使用实体框架。

我已经完成了一些MVC应用程序，并且发现了一个对我来说非常好用的结构。它是基于JPrescottSanders提到的Rob Conery的MVC店面系列的(尽管他发布的链接是错误的)。

因此，我通常尝试限制控制器仅包含视图逻辑。这包括检索要传递给视图的数据，以及将数据从视图传递回域模型的映射。关键是尝试使业务逻辑脱离这一层。

为此，我通常在应用程序中包含3层。首先是表示层的控制器。第二个是服务层，该层负责执行复杂的查询以及诸如验证之类的事情。第三层是存储库层，该层负责对数据库的所有访问。

因此，在产品示例中，这意味着我们将拥有一个具有诸如GetProducts()和SaveProduct(Product product)之类的方法的ProductRepository。我们还将具有一个ProductService(取决于ProductRepository)，该服务具有诸如GetProductsForUser(User user)，GetProductsWithCategory(类别类别)和SaveProduct(产品产品)之类的方法。诸如验证之类的事情也将在这里发生。最后，控制器将取决于服务层来检索和存储产品。

我们可以跳过服务层，但通​​常会发现控制器变得很胖，并且往往做得太多。我已经尝试过这种架构很多次了，而且它往往工作得很好，特别是因为它很好地支持TDD和自动化测试。