流浪青鸟

最近要做一个通用权限管理系统　的模块，请问各位有这方面程序　吗，有源代码更好，谢谢！！！

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

我是新来的...呵~~~

好久以前就开始看BLOG,但最近才注册了自己的BLOG.我是新人.希望多多帮助.

我的BLOG:<a href="http://www.cnblogs.com/catlff">http://www.cnblogs.com/catlff</a>

当然不是，都可以看到的。

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

为什么我在IE中看不到图？

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

能实现楼上所说，那就是大成拉。期待。。。

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

也算是吧，不过情况可能更多，比如直接访问数据库等

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

其实我还是建议去参考一下微软的SOA架构体系。

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