ASP.NET MVC模型
我刚刚开始使用ASP.NET MVC 1.0。我已经阅读了一些教程，但对于如何构建模型我没有任何好的想法。ASP.NET MVC模型
我一直在试验LINQ to SQL。不能说我喜欢那么多，但我会试一试。我更喜欢使用SQL存储过程，但它似乎并不与我的存储过程中的可选参数一起工作得很好。
该项目是一个原型，但我想从一个很好的设计开始马上。
该数据库可能包含大约50个表，存储过程将用于所有查询和更新。一些程序也会返回多个结果。如何设计这个模型的最佳方式？
欢迎任何想法。我应该甚至使用LINQ to SQL吗？我应该设计我的存储过程只返回一个结果吗？我感觉有点失落。
您可以在LINQ中使用存储过程。您只需用您的存储过程替换实体上的自动生成的语句。查看设计器中的实体（表）的属性以更改这些属性。您的存储过程将无法返回多个结果，因为它们需要映射到您的某个实体或自动生成的实体的集合上，即映射到单个类的集合上。
说了这么多，我会放弃它，而不使用存储过程。 LINQ代码是完全参数化的，所以你已经有了这个好处。您会发现LINQ允许您轻松构建查询，从而减少对存储过程中可选参数的需求，并且可能会导致更高效的查询，因为您无需在查询中构建额外的逻辑来处理可选参数。一旦你开始使用LINQ，我想你会发现代码中的强大功能和表现力会让你忘记使用存储过程。
对于复杂的查询，您可能仍然需要存储特效或表值函数 - 没关系。如果它们映射到现有实体上，则可以简单地将proc/function拖放到设计器中的实体中，并且在运行SQL的数据上下文中获得一个很好的方法并返回该实体的集合。如果不是，我经常为proc/function模式创建一个视图，将其用作实体，并将proc/function附加到它。
请问为什么你需要为这个项目使用存储过程？如果您正在使用现代数据库，他们今天几乎没有任何价值。使用良好ORM的参数化SQL将为您提供与存储过程相同的缓存执行计划和安全优势。
我会推荐，因为这是一个更好的方法来实现持久性的无知。恕我直言，这是任何设计模型的人的目标。你应该首先考虑对象而不是数据。
的最佳资源的周围已被Steve Bohlen“The summer of nhibernate”
而且LINQ to NHibernate可及，你可能需要编写任何动态查询的伟大工程，截屏系列。
你会注意到NHibernate的唯一痛苦就是XML，但是如果你真的喜欢ORM，你可以使用FNH来代替流畅的界面。
我发现NHibernate是建模域的最佳工具，因为你的对象是100％基础设施免费的，这可以让你做任何你想要的东西，而不必担心数据库。此外，如果你到任何类型的单元测试，这将让您的生活更容易：P
编辑的我回答你的问题的原因
部分原因是，我做了很多使用存储过程的系统后来发现后悔的决定。但在我的情况下，我有一个dba的要求，所以我无法摆脱规范。
如果您已经在研究LINQ to SQL，我只是鼓励您将NHibernate看作是实现持久性无知的另一个很好的选择。
当我从头开始思考问题数据时，它允许我在更高层次上工作，并利用.net平台解决问题。 TSQL有它的位置，但是如果你正在编写一个应用程序并且想要维护它 - 试着考虑你的域对象如何在内存中一起工作。
编辑2
不知道为什么我得到了下来投票建议NHibernate的 - 毕竟你说，你是开放比L2S其他
“的所有和任何想法，欢迎的事情应该我甚至使用LINQ to SQL？我应该设计存储过程只返回一个结果吗？我感觉有点失落。“
我的回答的一点是仅此 - 提供另一种“欢迎”的想法...
我个人觉得NHibernate的更引人注目现在LINQ存在。 LINQ-to-SQL对于很多人来说可能是一个非常好的ORM – ryber 2009-12-26 16:39:16
当然，但是现在你可以做同样的事情，NHibernate有一个LINQ提供者，可以使用更复杂的映射。例如：如果父数据与子数据分离的表中，则nhibernate很酷。但是对于LINQ to SQL，你必须在一张表中包含所有内容。所以对于这样的情况，你需要更多的灵活性，或者你知道模型（或数据库）的复杂性很大 - 恕我直言NHibernate是更好的工具。 – 2009-12-26 17:03:22
仅当它对您有用时才有用。如果你从不需要这些高级功能，那么它就是你必须跟上的另一个库。我很可能永远不会将它添加到项目中，直到它显然会有用。请注意，我对数据库有同样的感受。我认为对于许多企业.net项目（大多数是赞美CMS和工艺工具）可能是矫枉过正。我并不是说它不好或者什么，只是LINQ已经在那里，并且有很好的文档记录，并且在博客和SO上得到很好的支持。所以如果一个新手问我要去哪一个，我可能会说LINQ – ryber 2009-12-26 18:30:21