我正在学习 ASP.NET MVC，我喜欢它。但是，我对为模型命名空间的正确方法感到非常困惑。
在剖析 NerdDinner 示例应用程序时，我注意到 Models 文件夹中的所有内容都属于 Models 命名空间。数据映射类、存储库、错误规则管理等属于同一个命名空间级别。
我知道这个文件夹的灵感来自于 Rails 和朋友等框架，并且需要证明 MVC 标题中的 M 是正确的，但是；自动模型命名空间不会破坏编写可跨不同系统和实现可拆卸和可移植的业务逻辑的任何机会吗？
我应该在此模型命名空间下命名我的业务逻辑，还是应该完全忽略它并以更独立于框架的方式对我的类进行分类？
是否有任何复杂而优秀的 ASP.NET MVC 示例应用程序可以证明这一点？
我会以对你最有意义的方式对你的类进行分类，我怀疑他们在 Nerd Dinner 示例应用程序中使用了该命名空间，因为从学习的角度来看，开发人员总是看到它们在模型中是件好事应用程序的一部分。
就我个人而言，我不会在 Model 文件夹中放置任何东西，而是为我的实体 (App.Domain) 和域服务 (App.Services) 创建单独的项目。我还为这两个项目创建了 .Tests 项目。
我的开发意识告诉我，我们应该将我们的数据模型完全重构到另一个项目中。有些甚至在另一个项目中创建您的业务实体，并让它们由 Linq-Sql 类构成。
我认为 Scott 和 Co. 会采取至少将数据模型与表示层分离的方式。我们都知道关注点分离的好处，但他们将数据模型保存在 MVC 应用程序中的方式让我感到困惑。
关于更分层的方式还有更多建议吗？