<s:action name="xxxaction" namespace="/" id="aaaaa"/>
<s:select
label="命名"name="xxxxx"
headerKey="0"
headerValue="---请选择---"
list="#aaaaa.yyyy"
listKey="yyyid"
listValue="yyyname"
/>
能从后台action顺利获取到下拉数据需要注意以下几点：
1、struts.xml中的action别忘记配置
2、action中的返回的list别忘了生成get set方法，不然获取不了数据的
3、select标签上别忘记先要定义好action设置后id，然后才能list=”#id名字.返回的list名字“查询到数据
三层架构(3-tier architecture) 通常意义上的三层架构就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。区分层次的目的即为了“高内聚，低耦合”的思想。
1、表现层（UI）：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。
2、业务逻辑层（BLL）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。
3、数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、查找等。
二、重点讲解
1、首先，我们要清楚一件事情，三层结构不是.NET的专利，也不是专门用在数据库上的技术。它是一种更加普适的架构设计理念。
2、三层架构是包括数据访问层(DAL)、业务逻辑层(BLL)和表示层(UI),但是其实还有个实体层用于层和层之间数据传送。也叫做数据模型Model。
数据模型Model是为了封装数据，为了在三层间传输数据。独立于其他三个层次，Model不会引用这三个层次，但是三个层次都会引用它。Model是业务数据模型。
举个例子：DAL的一个insert方法，需要传递ID,NAME,PWD等等三个参数，使用实体层，那么传递的参数就只有有个User类，这样的好处就是减少系统出错的可能，提高开发效率~~
3、那么为什么要应用“中间业务层”呢？举些例子:
我们假设有一段登录代码，则可以这样处理Web程序，外观层负责接收前台页面的数据，然后传给中间层，中间层对数据进行处理，比如格式化，防SQL注入等等一些，这样的数据再传给数据访问层然后与数据库进行操作，比如与数据库的用户名和密码匹配等等一些代码。
“中间业务层”的用途有很多，例如：验证用户输入数据、缓存从数据库中读取的数据等等……但是，“中间业务层”的实际目的是将“数据访问层”的最基础的存储逻辑组合起来，形成一种业务规则。例如：“在一个购物网站中有这样的一个规则：在该网站第一次购物的用户，系统为其自动注册”。这样的业务逻辑放在中间层最合适：
4、在“数据访问层”中，最好不要出现任何“业务逻辑”！也就是说，要保证“数据访问层”的中的函数功能的原子性！即最小性和不可再分。“数据访问层”只管负责存储或读取数据就可以了。
5、完善的三层结构的要求是:修改表现层而不用修改逻辑层,修改逻辑层而不用修改数据层。
6、举一个三层架构的生活实例：
老张去饭馆，先跟服务生要菜单看，这就是表述层，再跟服务生点菜，服务拿着菜单去交给后台大厨，这就是业务逻辑层，大厨做好菜再让服务生拿上来，这就是数据访问层。
7、原则-三层具体应用：
DAL只提供基本的数据访问，不包含任何业务相关的逻辑处理。
UI只负责显示和采集用户操作，不包含任何的业务相关的逻辑处理。
BLL负责处理业务逻辑。通过获取UI传来的操作指令，决定执行业务逻辑，在需要访问数据源的时候直接交给DAL处理。处理完后，返回必要数据给UI。
8、各层间的引用关系
DAL/BLL/UI分别在不同的程序集中。
各个层间的引用关系：
UI->BLL->DAL
DAL所在程序集不引用BLL和UI；
BLL需要引用DAL；
UI直接引用BLL
JEECG V3采用架构技术：spring mvc+hibernate+Web UI快速开发库+activiti（流程定义）
V2到V3不是普通意义上的版本升级，应该理解为两个系列，两个系列版本会保持同步更新升级，保证使用V2版本的朋友，对于遇到的问题也能得到及时处理！