听老师说可以用别人的框架搭建,那么框架中的很多东西就自动生成了。
我现在基本上这样写:算不算是三层的?
显示的页面(界面层)--[调用]-->实体的访问方法-也就是对数据的增、删、改(业务逻辑层)--[调用]-->业务实体数据(通过CodeSmith生成数据库中的字段属性)+SqlHelper(数据层)--[操作]-->数据库

解决方案 »

  1.   

    框架有很多,也可以用CODESMITH之类的生成。推荐你搜这篇看下:
    "浅谈三层结构原理与用意"
      

  2.   

    buller 在你没 搞清楚前不要胡乱揣测,否则我鄙视你。
    我不知道就是不是到,所以才请教大家的~
      

  3.   

    buller 都为MM奋斗了??呵呵~~
      

  4.   

    由于刚开始接触三层:想问问大家,我按照自己上面说的那种方法写,还是用像动软.net代码自动生成器这种工具生成架构好。
    忘大家给点建议~
      

  5.   

    三层:界面层,逻辑层,数据层,也可以有个common就是字段属性
    楼主的是很常用的三层结构,现在好多地方都用多层结构了!呵呵,对于框架不熟悉,还在学习中!
      

  6.   

    界面层+事件处理是第一层
    事务,逻辑处理是第二层
    数据库操作是第三层
    三层体系好处是不依赖于特定的表现,同样的代码,换个界面层就可以从winform程序搬到webform程序的才算真正的三层
      

  7.   

    部署平台换了,只需要改UIL;
    DB换了,只需要改DAL;你的系统满足以上要求,就是真正的三层
      

  8.   

    我所做过的3层系统(ASP.NET1.1关于表单输入输出的):
    表示层:通过业务层返回的实体给控件赋值,或者将控件的值赋给实体
    业务逻辑层:接受表示层返回的实体进行处理然后传给数据访问层去加入到数据库或者从数据访问层获得返回的DATATABLE等转换成实体返回给表示层
    业务实体层:根据数据库中表生成对应的类.
    数据访问层:
    根据穿过来的实体去操作数据库,一般也是每个表对应一系列的数据访问方法,这些方法根据表放到不同的类里面去,这些类继承基类,这个基类就是类似SQL HELPER的数据库操作类
      

  9.   

    既然分层了,不光是分层,还要考虑接口设计,依赖注入,模式设计
    否则分层也没体现应有的价值想初步了解MVP分层,建议看看PetShop4.0
    虽然不复杂,但基本对入门MVP来说已经感觉受益匪浅了
      

  10.   

    winform程序搬到webform程序的才算真正的三层。
    已经我也听到过类似的说法。使用框架用很多好处的,对于维护来说比较简单。
    一层层依赖,关系比较明了,后期有变动时或者有问题时,网网能定位到是哪层出的问题,修改比较容易。
    .net有很多这样的例子的。
      

  11.   

    winform程序搬到webform程序的才算真正的三层。 
    已经我也听到过类似的说法。 ------不要乱说!