听老师说可以用别人的框架搭建,那么框架中的很多东西就自动生成了。
我现在基本上这样写:算不算是三层的?
显示的页面(界面层)--[调用]-->实体的访问方法-也就是对数据的增、删、改(业务逻辑层)--[调用]-->业务实体数据(通过CodeSmith生成数据库中的字段属性)+SqlHelper(数据层)--[操作]-->数据库
我现在基本上这样写:算不算是三层的?
显示的页面(界面层)--[调用]-->实体的访问方法-也就是对数据的增、删、改(业务逻辑层)--[调用]-->业务实体数据(通过CodeSmith生成数据库中的字段属性)+SqlHelper(数据层)--[操作]-->数据库
"浅谈三层结构原理与用意"
我不知道就是不是到,所以才请教大家的~
忘大家给点建议~
楼主的是很常用的三层结构,现在好多地方都用多层结构了!呵呵,对于框架不熟悉,还在学习中!
事务,逻辑处理是第二层
数据库操作是第三层
三层体系好处是不依赖于特定的表现,同样的代码,换个界面层就可以从winform程序搬到webform程序的才算真正的三层
DB换了,只需要改DAL;你的系统满足以上要求,就是真正的三层
表示层:通过业务层返回的实体给控件赋值,或者将控件的值赋给实体
业务逻辑层:接受表示层返回的实体进行处理然后传给数据访问层去加入到数据库或者从数据访问层获得返回的DATATABLE等转换成实体返回给表示层
业务实体层:根据数据库中表生成对应的类.
数据访问层:
根据穿过来的实体去操作数据库,一般也是每个表对应一系列的数据访问方法,这些方法根据表放到不同的类里面去,这些类继承基类,这个基类就是类似SQL HELPER的数据库操作类
否则分层也没体现应有的价值想初步了解MVP分层,建议看看PetShop4.0
虽然不复杂,但基本对入门MVP来说已经感觉受益匪浅了
已经我也听到过类似的说法。使用框架用很多好处的,对于维护来说比较简单。
一层层依赖,关系比较明了,后期有变动时或者有问题时,网网能定位到是哪层出的问题,修改比较容易。
.net有很多这样的例子的。
已经我也听到过类似的说法。 ------不要乱说!