在我的第一个 ASP.NET MVC 应用程序中，模型是表和类之间的简单 O/R 映射，由实体框架管理。
现在我想给这个骨架加点肉，并为生成的类介绍业务方法。在 ASP.NET MVC（使用实体框架）中推荐的方法是什么？我最喜欢的是也可以在服务层中使用的解决方案，没有 ASP.NET MVC 引用，因此相同的域逻辑也可以在桌面客户端中重用。
从技术上讲，我认为即使需要刷新 O/R 类，也应该可以以保留额外业务逻辑的方式扩展生成的类。（然而，这更像是一个与实体框架相关的问题。）
编辑：非常感谢您的贡献，以及有关下一版本实体框架（4.0）的信息。构建两组类，一组是自动生成的，用于表示持久层中的数据，另一组用于实际的业务逻辑，这听起来很有趣。
在 MVC.Net 中，模型是定义最不明确的部分。在我看来，它基本上是您应用程序的其余部分（即与视图或控制器无关的任何内容）。您的应用程序的 O/R 映射部分也应该在“模型”之外，因为这更像是一个数据层。模型应该真正处理业务对象并创建数据视图以传递给视图。
对此有很多不同的看法，但我认为最好不要将 MVC.Net 视为传统的 MVC 架构。
将您的业务层抽象到另一个项目中，然后使用结构映射之类的东西将其实例传递到您的 mvc 控制器。然后，您可以从控制器调用此业务层以检索您的业务实体（模型）并将它们传递给 UI。这将允许您在桌面应用程序中重用您的业务层。
如果您现在使用的是 EF v1.0，实体框架会非常侵入您的应用程序，这意味着您不能很容易地创建 POCO。扩展模型的方法是使用部分类。因此，当您刷新模型时，您所做的部分类仍然有效。Entity Framework 团队意识到这是一个问题，并在下一个版本（EF V4.0）中对此进行了改进。
NHibernate 更加友好，允许您轻松扩展业务逻辑。
我真的认为 Jeremy D. Miller 的这篇博文非常善于指出问题。
不仅是肉，还有一些衣服和风格可以添加到这个项目中，让它看起来很别致。这取决于您为该项目所拥有的时间。如果你有时间，我建议你看看 TDD 和可以与 TDD 一起使用的框架，例如 Castle、NUnit、Moq 等。
正如您提到的，服务层对于任何项目都是必须的，但是使用这些类型的框架，您可以设计更健壮的架构。