拥有业务逻辑层时仍需要模型层吗？ [英] Still need a Model layer while having a Business Logic layer?

问题描述

在asp.net解决方案中，当你有一个商业项目时，你会对Model项目做什么？

在界面上，我觉得很容易并且有效地使用映射到执行所有CRUD的类的objectdatasource。我将该课程放在了Business项目的旁边。该类包含linq查询，用于从/向数据库获取和设置数据。

那么什么留给Model项目呢？界面与Business项目谈话很好。在这里可以做更多或更好的事情吗？

这里有更多的问题，如果你使用Linq to SQL，那么你的数据访问层应该是什么？只有DBML文件？

解决方案

模型是提供数据的任何内容。

这可以是一个或多个分布在整个机器上。

对于小型系统，只有分割层的开销 - 所有这些都是复杂的。

如果您改为有大量的并发用户，那么你可能需要在缓存业务对象的多个服务器之间分配负载。

那么你的一层就不起作用了。

在小型系统中我曾经在那里完成了除了数据库服务器以外的数据访问所没有真正的单独层。

更大的系统，你需要更复杂的方法

hi, 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?

解决方案

The model is whatever provides your data.

That can be one layer or several spread across machines.

With small systems there's only overhead in splitting up layers - all it adds is complication.

If you instead had huge numbers of concurrent users then you may need to spread load across multiple servers caching business objects.

Then your one layer just doesn't work.

In small systems I've worked on there's no real separate layer at all for my data access other than the database server of course.

Larger systems, well you need a more sophisticated approach.

这篇关于拥有业务逻辑层时仍需要模型层吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！