日期:2014-05-18  浏览次数:20376 次

请问使用三层结构中,Model实体类是用来做什么的,使用实体类有什么好处呢?
如题。
还有,实体类应该放在哪个层里面?

------解决方案--------------------
不是放在哪个层,而是供这些层做为类型使用的
当你要添加或修改字段的时候,做的改动最小,因为你方法的类型是实体类型,所以很多方法都是不需要做改动的
而且这也体现了面向对象的封装的原则,信息隐藏在类中
------解决方案--------------------
实体类其实对应数据库中一个表,实体类的每个属性对应表中相应的字段,使用实体类属合面向对象编程的思想,把一个表封装成一个类。
------解决方案--------------------
偶做的实体内都是一表对应一个实体类,这样做的好处是当数据库中修改字段名的时候只用修改一下DAL层里相应的代码就行了,不影响其它层和界面上相关数据的绑定.
但是偶对三层也不是很了解,有个问题想在这问问,就是我在前台要显示的数据都是几个表联合查询出来的,这样在数据绑定上,我的实体类也基本上没用到.现在偶做的这个项目中有一块都是这样的情况,感觉这个实体类在这一块上就没用.指大虾指点一下.
------解决方案--------------------
实体类做为数据容器,在层间传递
------解决方案--------------------
简单的讲,实体类是与表的一种对应.你先这么简单的理解吧.慢慢会有更深的理解.
------解决方案--------------------
实体是用来存放信息的
实体可以分为持久化对象(与数据库对应)和业务对象(包含业务信息对象)
这两种对象之见是可以转换的. (我认为po/vo 对于SOA下的开发已经不是必须的了.我认为有PO就够了,并且可以更好的布局和使用,机于我理解的SOA :( http://blog.csdn.net/Oceanson/archive/2007/05/17/1613879.aspx)

实体有很多好处,我举一个比较偏的例子
你有一个查询控件,包含了许多查询信息.比较bad的作发是在UI层根据用户输入的信息编辑一个sql 直接调DAL层拿数据.
稍微好点的做法在业务层写一个很多参数的方法,把用户输入的信息传递到业务层处理.这样写的缺点是你加一个参数就要改一次接口.当然你可以在c#里用Parameter+object[],或者用2.0中的Collection <T> .但第一种方式业务层很难处理,你的list必须是有规律的.第而种方法最大的缺点是范形不能用object.
我认为最好的方法就是使用实体.你有一个某中query的实体,把所有信息记录进去,传递到业务层处理.

------解决方案--------------------
实体类是与表的一种对应
------解决方案--------------------
误导呀

1、当你要添加或修改字段的时候,做的改动最小

实际上,改动往往很大。

2、实体类其实对应数据库中一个表

这么说的话,就不要说OO了,直接说面向数据库好了。
如果这么做的话,添加字段,改动更大。


正确的做法是,先有实体,在有表。但是有多少人能做到这一点呢?我是做不到的。

实体里的数据是放在内存里的,是不持久的(不能长久保存),要把这些数据长久保存下来就要持久化一下。就是把数据保存在数据库里。