我们在开发WEB应用系统时总是谈到技术架构，采用SSH框架就等于有了好的技术架构了吗，我认为不然，SSH框架只是MVC2架构设计的基础实现框架，在做具体系统设计时还要考虑具体的技术架构设计要素：
1． 实体主键的设计 是使用逻辑主键还是使用业务主键，更多的是一种个人偏好。但是在使用Hibernate等ORM框架时，逻辑主键应该优先考虑。
2． 用户的设计 系统开发中用户的设计是最基础的，基于现在各系统间整合、协作的要求，必须有统一的通行证的设计，我不赞成将前台用户，后台用户等分开来的设计，以Passport为基础，扩展用户的Profile和UserRole, UserGroup的设计更可取一些，这样也更便于以Passport信息做统一的用户集成。同时在集成时考虑LDAP的支持。
3． 权限框架的设计 最普遍的权限设计主是以角色为基础的权限设计(RBAC)。通过UserRole, UserGroup等对象对受限访问的资源授权。在BS系统中这些资源体现为不同的URL信息。在鉴权时，则可以使用Filter, BaseAction或者Interceptor来处理，与业务逻辑基本隔离。
4． 系统构建及配置 可基于ANT或MAVEN2做系统构建的工具，使过程更自动化。配置信息现在通用的是XML配置文件，尽量使用Annotation来做配置，可以简化配置文件，保持一致的、同步的配置信息版本。
5． 通用组件及代码的整理 输入参数编码的处理，全局的系统异常处理，日志输出的原则，发送MAIL的功能，任务调度功能，线程并发处理组件，数据导入导出功能，日志分析功能，系统审计功能，列表分页组件，验证码组件，图片处理组件，WebService功能的封装，JS库的选择（包括AJAX）。这些都是最基本的组件及公共代码。工作流引擎/规则引擎/业务流程引擎也是越来越基础的功能。
6． 子系统的划分及接口设计 一个子系统的核心功能应该越少越好，并支持良好的扩展接口，有利于系统的稳定和维护。
7． 关键性能点及大数据量对象的设计考虑，比如上万级节点的树结构设计及查询，百万级用户的存储和查询。
8． 数据库的设计考虑 即使我们是面向对象的设计，从业务对象开始再映射到数据库表，也需要考虑数据库具体实现时的性能问题。在对象关联时要有所限制，可使用Lazy方式处理，并提供单独的数据访问接口。同时要考虑在系统扩展时的要求，比如数据库的读写分离，数据库集群，数据切分等操作。数据库约束也是必要的，只是可以在上线后的系统里删掉以提高性能，在导数据时一定要注意加上约束。
9． 事务划分 需要事先规划好长事务的业务处理过程，划分好各事务边界。
10． UI页面组件的划分 CMS和Portal平台无疑是一个好的解决方案，达到了页面组件设计的最大化，需要考虑的就是二次开发的学习成本及性能的测试。即使自己来设计开发也最好可以借鉴这些平台的实现思想。
11． URL的映射 支持RESTful处理的URL更有优势。需要从架构设计上考虑给予支持。
系统部署及服务器规划 Web Server和Application Server如何选择，如何部署需要在系统原型阶段尽早确定并做好基准的性能测试，以达到满足业务的需要。尽早考虑负载均衡，系统集群，数据库集群，数据备份，HA，FailOver等基本要求和扩展手段。事先规划好需要静态化处理的资源及策略。
转自：http://blog.csdn.net/netv/article/details/4136922
==========================权限
很多人都知道以角色为基础的权限管理设计（RBAC），但是大部分人似懂非懂，不知道完整的权限管理系统都包括哪些内容。
在此以权限管理的使用场景来说明一下完整的权限管理内容。
一是鉴权管理，即权限判断逻辑。
1. 最基本的权限管理就是菜单管理，用户没有权限的功能模块在菜单节点上是不显示的。（很多人以为这就是权限管理！）
示例：普通业务人员登录系统后，是看不到【用户管理】菜单的。
2. 功能权限管理，B/S系统的功能体现为URL，所以功能权限管理主要是针对URL访问的管理。（很多人都不清楚权限管理的对象是什么？）
示例：
经过授权，部门经理可以查看【用户管理】菜单，并查看部门用户信息，但权限设计要求，该部门经理没有添加用户的权限。
所以在访问【添加用户】的功能（URL）时，应该有没有授权的提示信息。
同时在【用户管理】页面上，【添加用户】的按钮应该灰色显示，不能点击。
3. 行级权限管理
示例：
论坛管理员，权限设计要求 A能管理论坛 【新闻版块】，不能管理论坛 【技术交流】
此时的权限设计就应该根据论坛的相应ID来判断权限信息。
4. 列级权限管理
示例：
业务权限设计要求，除销售人员以外，其他用户不能看到客户的联系方式信息。
此时的权限设计要判断相应的字段（列）是否可以显示。
5. 组织机构/部门级数据权限管理
示例:
业务权限设计要求，销售一部的人员只能看到本部门的销售订单，销售二部的人员只能看到本部门的销售订单，但销售经理可以同时看到
销售一部和销售二部的销售订单。
此时的权限设计就要根据销售订单数据本身的部门属性来做判断
6. 范围型业务数据权限管理
示例：
大卖场销售人员在下销售订单时，要选择相应的产品所在仓库信息。
业务权限设计要求，【国美】的销售人员在选择仓库的下拉列表中不能看到【广州仓库】，而【大中电器】的销售人员在选择仓库的下拉列表中不能看到【北京顺义仓库】
二是授权管理，即权限分配过程。以上的权限管理内容都要通过系统的授权功能来分配给具体的用户，授权功能应该足够灵活。
1. 直接对用户授权，直接分配到用户的权限具有最优先级别。
2. 对用户所属岗位授权，用户所属岗位信息可以看作是一个分组，和角色的作用一样，但是每个用户只能关联一个岗位信息。
3. 对用户所属角色授权，用户所属角色信息可以看作是一个权限分组，每个用户可以关联多个角色。
4. 角色直接关联具体的功能权限（URL），也可以关联负权限，即此角色关联的权限不能使用负权限功能。负权限具有优先级别。
5. 分级授权，系统管理员可以将自己拥有的权限信息授权给其他用户。即可以设置分级管理员和超级管理员。
以上才是一个完整的权限管理系统，你有这样的完整权限的设计
参考：http://blog.csdn.net/netv