流浪青鸟

我认为各模块还是封装成单独的DLL好，不过要集成一个相同的接口，这样对以后划分版本什么有很大的好处，最好设计一个公用的界面载入模块，然后根据配置载入相关的模块。

O/R Mapping的解决方案我也想知道大家的看法
  回复  引用  查看    

你的结构挺不错的，如果我设计的话，也大概是这样的方式，采用不同的模块是非常有好处的，可以把层次分的很清，以后修改维护也容易些，在UI中不需要使用多模块的，只要把模板以目录的方式区分就可以了，我会把"公用商务逻辑组件"与"Common层"合并起来，变成一个叫做"Framework"层即可，用于公用信息的处理，比如一些系统常量，公用类库等。这也是我SPL系统开发框架的推荐方式。

  回复  引用  查看    

我认为各模块还是封装成单独的DLL好,而且接口和实现要放在不同的模块.
  回复  引用  查看    

使用SPL的话，会在Database上面加一层SPL,所有对数据库的访问都会经过SPL进行。
  回复  引用  查看    

这样做了以后，相当于将每个工程里面再细分为多个文件夹，包括业务外观，业务规则，和表示层。当然，这样做会导致系统中有很多个工程，IIS里面也有很多个web应用程序。我们知道，Session无法在各个应用程序中互相传递，所以，我借鉴网上的文章，实现了多个工程之间的Session共享，系统及用户信息的传递问题解决了。

希望大家继续讨论，关键我希望知道，这样搭建的架构是否能承载较大的负荷，不知大家是否有这样的使用经验？
  回复  引用  查看    

TO idior：
能否再说得详细一点？谢谢了！
  回复  引用  查看    

你的模块和工程的概念混淆了。模块放在一个dll中还是放在多个dll中只是区别在部署中。同时如果在多个dll中，如果修改了一个模块，就只更新这一个dll就可以了。对于web应用应该还是只有一个工程的，也即一个应用程序，否则可能就会比较麻烦。模块的划分是基于类的，一个模块是一组类的集合，也可能一个模块就只有一个类。而你多个类文件是放在一个工程里面还是放在多个工程里面，或者多个类放在一个文件里面，这都不是逻辑设计的问题了。
  回复  引用  查看    

TO ocean：

先谢谢你！

不过我还是不太明白，我的想法是将多个类放在一个工程里，同时也会包括很多个文件，我们可以说这不是逻辑设计的问题，但怎么说也算是架构设计的一部分啊，直接影响到部署啊。所以我还是不明白，还请多多赐教哦：）
  回复  引用  查看    

o/r mapping我目前采用的是xpo，不过我认为现阶段似乎.net o/r mapping的实现条件还不成熟，建议可以等一下。
  回复  引用    

好像ado.net2.0会出一个transaction空间，到时候这种事务处理挥好处理一些。估计2.0出来之后，o/r mapping又会改动不少。
  回复  引用    

楼上的是否是结巴阿，一句话说了3遍

请问为微软的企业框架里面的Microsoft.Enterprise.Data.dll将来变化的程度会有多大(.net 2.0)新项目在考虑是否使用
  回复  引用  查看    

接口和实现要放在不同的模块.

就是当实现变化的时候,上层(由于使用接口)不需要改变. 3188.NET 不是他结巴,你可以发现最近老有这样,我自己就发生过,cnblogs可能哪里出了点问题.dudu?
  回复  引用  查看    

可能是提交评论时速度慢, 以为没有提交, 然后连续点击“提交”按钮引起的。我最近发表评论时没碰到这个情况, 这部分的程序最近也没有改动。
  回复  引用  查看    

我认为顶楼的架构基本上可以定义为：不严格的带Service Layer层的3层架构。所谓不严格是因为，顶楼的架构允许跨层调用。但我认为跨层调用要限制，最好是不允许跨层调用。如果要有跨层调用，我认为也是前端的查询可以。

其实我更倾向于将业务外观层叫为Service Layer层，这就和微软的SOA架构和相像了。但是要注意的一点是，Service Layer层可以有很多个，比如支持外部调用的Service Layer可以是Web Services实现，支持内部调用的Service Layer层可以就是一个简单的接口实现。

另外我认为顶楼的划分模块一、模块二、等确实没有必要，再架构设计阶段，我认为确实没有必要考虑如何物理部署的问题。

其实我还是建议去参考一下微软的SOA架构体系。
  回复  引用  查看    

@浅水滩 :
我非常不同意你的观点，为何不推荐跨层调用，给个充分的理由先。
Web Service应该属于表示层，不应该把Web Serivce作为服务层看待，因为不是系统都需要Web service的。
至于分模块一是为了代码清晰，也是为了团队开发分工。
  回复  引用  查看    

@听棠.NET：谢谢你的回复

关于跨层调用，我的确不推荐。原因是跨层调用将引起系统结构的混乱，比如现在架构中经常用AOP在业务层来做日志或者权限控制，若前台直接去调用数据层，那AOP就给完全跨过。举个例子就是，一个公司有总经理、部门经理、项目经理、普通员工，如果总经理老是直接去指派普通员工，而这些指派都不让项目经理、部门经理知道，试问一个公司怎么可以管理好？还有一个典型的例子是TCP/IP 7层协议，都是不允许跨层调用的。当然有时出于效率的考虑，在一些查询上做跨层调用，我并不反对。

Web Services层绝对不属于表示层，Web Services应该看出是业务层的代理，是一个非常瘦的层。Web Services层是Service Layer层的一种实现而已，Service Layer的出现是为了解偶表现层和业务层。

至于模块的划分，如果是物理上的划分，我认为是不应该在架构中做，但如果是逻辑上的划分，我认为是可以的。


  回复  引用  查看    

对于一些大型的企业应用开发，将不同的模块完全独立，如Accounting, Sales Order, Purchase Order等，分别开发为独立的应用程序。这样，可以将任务分解，可以考虑这样做。

不过，有一个问题请教一下：你是否还提供一个统一的UI给用户？
*
另外，如果项目不是很大，可以考虑将UI层统一。

  回复  引用  查看    

本人有个问题，我想知道事务控制 在哪层处理掉，是否要用AOP
  回复  引用    

to 青鸟
**********************************************
这样做了以后，相当于将每个工程里面再细分为多个文件夹，包括业务外观，业务规则，和表示层。当然，这样做会导致系统中有很多个工程，IIS里面也有很多个web应用程序。我们知道，Session无法在各个应用程序中互相传递，所以，我借鉴网上的文章，实现了多个工程之间的Session共享，系统及用户信息的传递问题解决了。
**********************************************

我个人觉得，同一模块分层后应该放置在不同的DLL中，你这里说的多个文件夹是什么意思？另外在表示层以外的层次当然可以有单独的工程，但是表示层应该适当的统一，你可以把公用的文件以及文件夹放在一个项目里面，而把不同的模块，比如生产模块、销售模块放在不同的项目中，但应用程序只有一个。你觉得是否可以？

  回复  引用  查看    

我也不赞成把ui分布到不同的dll（应用程序中）这种做法
虽然可以带来模块更好的独立性，但象session，交互等能力变弱，反而得不尝失。（不知道是否有更好的办法来解决这个问题）
跨层调用我觉得 浅水滩 的分析很有道理
  回复  引用  查看    

功能拆借是一定，也是必须的，但重要的是它们直接的组织关系！
建议将公用逻辑组件和Common层合并（同意听棠.NET的说法），然后将UI层、业务外观层、业务规则层都分别设计成相应的Framework，对外和对内都有统一的接口，具体的模块必须生存在相应的Framework中，它们之间的调用必须通过Framework调度。
这样的系统是框架紧偶合、模块松偶合，弹性是最好的。
我也很同意浅水滩的说法，应该尽量避免跨层调用，这样偶合度加大了。
我以前做过的一个产品就是这个样子设计的，10多个人在上面开发了多年，代码超过100万行，系统相当的健壮。
不过这个也是有缺点的，就是调度太多，经常出现效率低的问题（这个和公司越大越官僚很像~_~），我们的解决方法是找到效率低的地方进行极端优化，效果还是不错的。不过有时候就会破坏系统的偶合度，鱼与熊掌不可兼得呀
  回复  引用  查看    

@Rickie：用户直接请求的UI是统一的，但该UI会加载其他工程的控件，以实现不同的模块。

@byrybye：事务处理我的想法是直接通过O/R Mapping处理掉。

@纯爷们：我的意思是将整个工程拆分开来，从功能模块来讲，一个功能模块就是一个独立的WEB应用程序，再在里面进行分层，包括业务外观、业务逻辑层和表示层等。你所说的公用部分我肯定会将他们放在一起，但具体功能模块可能会拆分成不同应用程序，但我的确有点这样做后的运行效能。

@Leon.Zhou：你所说的极端优化是打破原有调用模式，直接跨层进行调用，从而提高效率么？

感谢大家的精彩发言，真理总是越辩越明嘛，先谢谢各位了！还请大家继续拍砖哦！
  回复  引用  查看    

也算是吧，不过情况可能更多，比如直接访问数据库等
  回复  引用  查看    

有没有把 ui分布到不同的dll ，但应用只有一个。
  回复  引用    

能实现楼上所说，那就是大成拉。期待。。。
  回复  引用  查看    

不过UI的确分布到了不同的dll，但应用程序只有一个。
  回复  引用  查看    

为什么我在IE中看不到图？
  回复  引用  查看    

呵呵，现在看到了，是不是只有回复后才能看到：）
  回复  引用  查看    

当然不是，都可以看到的。
  回复  引用  查看    

不是很赞成分成多个dll,然后去共享Session.
1 增加系统的复杂度
2 中型系统的概念如何界定
3 多服务器如何负栽均衡


  回复  引用