在拥有业务逻辑层的同时还需要模型层吗？
在 ASP.NET 解决方案中，当您有一个业务项目时，您会对模型项目做什么？
在界面上，我发现使用映射到执行所有 CRUD 的类的对象数据源非常简单且有效。我将该类放在商业项目中。该类包含从数据库获取数据或向数据库设置数据的 linq 查询。
那么 Model 项目还剩下什么呢？界面与业务项目的对话很好。这里还有什么可以做的更多或更好的事情吗？
还有一个问题，如果您使用 Linq to SQL，那么您的数据访问层中应该有什么？只有 DBML 文件吗？
感谢您的时间和精力
最好的问候
in a asp.net solution, what would you do to a Model project when you have a Business project?
On the interface, I find it very easy and effective to use an objectdatasource mapped to a class which does all the CRUD. I put that class in side the Business project. The class contains linq queries that gets and sets the data from/to the database.
So what is left to the Model project then? the interface talks to the Business project just fine. Is there anything more or better can be done here?
and here's more question, what is supposed to be in your data access layer then if you use Linq to SQL? only DBML files?
I appreciate you time and effort
Best regards
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
普遍接受的最佳实践是使用视图模型模式。
视图模型基本上是业务对象的扁平化表示，对应于在特定上下文中查看该业务对象。视图不是将业务对象传递给视图，而是在视图模型的上下文中呈现。
虽然我可以用大量代码示例详细解释实现过程，但这毫无意义，因为 Jimmy Bogard 已经写过“我们如何做 MVC - 视图模型”，在阅读之后您将更好地理解如何实现这种方法以及这样做的原因。那篇文章。
The commonly accepted best practice is to use the View Model Pattern.
A view model is basically a flattened representation of a business object that corresponds to viewing that business object in a certain context. Instead of passing the business object to the view, the view is rendered in the context of the view model.
While I could explain the implementation in excruciating detail with plenty of code samples, it would be pointless, because Jimmy Bogard already wrote "How we do MVC - View Models. You will have a much better understanding of how to implement this approach, and the reasons for doing so after reviewing that article.
如果你真的想要它，你就不需要任何东西：P。模型文件夹主要放在新的 MVC 项目中作为指导，以展示如何使用 MVC 进行关注点分离。如果您的业务层已位于另一个项目或不同的文件夹中，则可以将其删除。该文件夹在 MVC 架构中没有特殊含义。
You don't NEED anything if you really want it :P. The model folder is mostly put in new MVC projects as a guideline to show how to do separation of concerns with MVC. If your business layer is already in another project, or a different folder, then you can delete it. The folder has no special meaning in the MVC architecture.
如果您使用 ASP.NET MVC，那么我会执行以下操作：
有一个“本地”模型，充当 BLL 和控制器之间的接口。本质上控制器应该只知道您本地使用的对象。
这可能涉及模型“存储库”部分中的映射代码； AutoMapper 就是一个很好的例子。
造成这种情况的原因有几个：
If you're using ASP.NET MVC, then I'd do the following:
Have a 'local' model that acts as the interface between the BLL and the Controller. Essentially the controller should only know about objects that you use locally.
This will likely involve mapping code in the "repository" part of your Model; AutoMapper is a good example of something to use for that.
There are a few reasons for this: