讨论下开发中型网站用什么架构比较合适?顺便散分一百.说的好的多给分.随机抽取2名给20分~其余平分.

单类结构?简单三层结构(Model,DAL,BLL)?工厂模式三层结构(Model,DAL,IDAL,DALFactory,BLL)?还是其它??说个维护最方便,开发速度最快的.最好讲讲理由.给个连接也可以.现实情况:我们有三个人做开发.需求不是很明确,可能会有改动.如果是开发OA呢?

解决方案 »

  1.   

    单类结构是什么?简单三层结构应该是UI,DAL,BLL吧? model不能算一层.....3个人开发也只是个小项目而已，如果业务逻辑并不复杂那根本就不用在架构上花太多的心思，把公共类库整理一下，直接把业务逻辑放在存储过程处理，不用严格分层，保证可以快速开发
      

  2.   

    简单三层结构(Model,DAL,BLL)
    选择的理由我只会搞这个
      

  3.   

    spirng.net + nhibernate 
    或者 web--> bll -->IDAL --> nhibernate我用后者.
      

  4.   

    偶说一句，其实偶觉得现在什么三层多层架构，都已经过时了。
    现在用松散耦合。分布式应用，比什么都好。IBM的SOA,ESB,理念，大小系统通吃。
      

  5.   

    偶用的是三层结构（BLL+DAL+Model)！
    个人感觉还可以，也可以多人开发，最后再整合！
      

  6.   

    学习ING……
    我也不怎么清楚
      

  7.   

    要回答这个问题,首先看看最经典的企业级架构WebUI|WinUI|WebService:界面和webservice
    Business Facade:业务层的包装
    Business Rule:业务规则
    DataAccess:数据访问SystemFramework:框架,为上面的层提供一些公共的方法和工具类,比如配置文件,日志和缓存等等Common:这是可选的,一般放层间传递的实体一般网站的框架就从这里裁减出来,
    从最上层开始说,webui,一般网站当然是少不了的,webservice就不一定了,如果你需要为合作伙伴提供服务,自然就可以保留,或者你决定采用smartclient(微软提出的基于webservice的客户服务模型),则必不可少业务层包括business Facade和BusinessRule,可能有些人会觉得多余,但实际上,facade是对业务层提供方法的一个包装,不管下面business rule怎么变化,这个层相对固定,而business Rule就是专门的业务逻辑了,如果没有复杂的业务逻辑判断,这两层可以合并,对中型网站来说,业务层用一层是可行的.数据访问层不用解释太多,不过我解释下楼主的所谓factory,实际是对上层提供一个统一的数据访问层接口,然后可以许多实现,比如针对sqlserver的实现,oracle的实现等等,于是可以实现数据库的切换,现在所谓的provider模式,见微软的dataaccess application block,就是这样一种实现,给出一个统一的接口,然后针对不同数据库写不同的实现,而且上层和数据访问层间是通过配置文件来连接的,于是可以实现动态切换,当然这是一个好办法,不过一般如果网站的数据库相对固定,(一般不会出先切换多种数据库的情况),就完全可以不用这样实现了.common里面放业务实体,很多网站都是这样作的,但是当然也有局限性,因为一般common里放的是在层间传递数据的统一格式,也就是所有的层次都是由这个来传递数据.但有时候,各个层间可能需要不同数据传递格式.中型网站,一般三层,一个界面层,一个业务层,一个数据访问层足够了,因为,除非是商务网站,一般业务逻辑不复杂,无外乎是一些有效性验证工作,这是两个业务层就多余了,winui,webservice一般可能不需要,数据库也不用切换.systemframework,看起来是一个杂货铺,但其实是一个比较重要的程序集,他一般是许多次开发经验积累的结果,里面的日志类,缓存类,配置文件访问类,断言,还有测试工具,都可以被在许多网站中重复使用,所以一个好的框架集,简直就是一笔财富,开发的时候应该注意经常把好的东西,通用的东西放进来,然后用适当的命名空间加以分类,以后会收益无穷开发过程和方法,是另外一个话题,但是既然楼主提到了,我就简单说说,软件从需求分析,建立模型,到代码是一套流程,比较严格的方法是用rup,但是这个对前期需求要求比较清楚,计划制定与建立模型需要相当的时间和工作量,对于小项目,小团队,是得不偿失,而且rup重在从需求建立模型和架构,而网站开发的模型和架构都比较成熟,不用每次都从0开始,所以,简单一些,实用就好,可以考虑敏捷开发,这种开发速度较快,对不确定的需求支持好,讲究测试和重构,具体不详述,有兴趣参资料,一搜一把
      

  8.   

    用三层，业务、数据、表示即可。
    这东西没尽头的，自己开发练手，当然要有挑战性。一个好的站点要求：
    易于维护。
    可升级性，有时需要时行代码扩充、功能增加。
    站点的开发永远不可能一次完成，总是不断地修改。成功的站点关键是易于修改。
    在基础设计的时候，当然是用抽象类、存储过程为主的基础数据类、页面类、商务类、错误处理类：DbObject.cs,youwebpage.cs,BizObject.cs,AppException.cs
    用css,页头，脚注、可重用的控件。建立坚实而又没有太多限制的、可升级的基础设计，在其上建立其他部分开发的模块，提供能够被多个具有不同经验并能够产生一致辞解决方案的程序员所使用的基础设计。可升级性、灵活性、可重用性（对象的层次结构、继承性和重用性）。
    独立必，大家的工作不影响对核心基础设计代码。
    目前我也在学三层结构，所以一半抄书，一半自己心得从书中搞来。
      

  9.   

    Web页一层、后置类一层、传递动态SQL一层（包括存储过程）、数据库一层