闲暇时间看了下前些天买的关于CSLA框架的书，摘抄了一些。
...剩下的方案是把业务逻辑集中在部署在客户机（或web服务器）的业务逻辑层，这样UI层就可以访问业务逻辑，部署在应用服务器业务逻辑层中，这样业务逻辑就可以有效地与数据访问层交互。这样的做法能同时获得这两种方案的好处：丰富交互性的用户梭和访问数据库（或其他数据源）时高效高性能的后台处理。
在没有应用服务器的简单情况下，业务逻辑只被部署一次：在客户机或者web服务器上。
在理想化的情况下，业务逻辑在与用户交互的时候会与UI代码运行在同一台电脑上，而在访问数据库的时候会与数据访问代码运行在同一台电脑上（像前面讲座过的，所有的这些代码运行在哪台电脑上取决于系统物理的架构）。业务逻辑必须提供一个友好的接口方便UI开发人员使用来调用数据验证和处理的逻辑，而且还必须能高效地使用数据访问层来读取和写入数据。
用来解决这个看起来很棘手的需求的工具就是封装了应用程序的数据和相关业务逻辑的移动业务对象。一个合理构建的业务对象可以在网络中从一台电脑移动到另一台电脑，几乎不需要你做什么。NET框架本身会处理底层的细节，而你可以把精力集中在业务逻辑和数据上。
如果很好地设计并实现了移动业务对象，你就可以让。NET框架在网络中按值来传递你的对象，也就是自动把对象从一台电脑复制到另一台电脑。这需要额外很少的一点儿代码。你可以把你的业务逻辑和业务数据移动到UI层所在的电脑，然后在需要数据访问的时候将他们转移到数据访问层所在的电脑上。
同时，如果你把UI层和数据访问层进行在同一台电脑上，那么。NET框架就不会移动或复制你的业务对象，这两层都直接使用它们，这样就不会造成性能降低或额外的开销，你也不必为此作任何事情，。NET会自动检测到该对象无须被复制或移动，因此也不会作任何的动作。
业务逻辑层会因为而变得轻便灵活或移动，而且能适应所在的应用程序部署的物理环境。因此，你可以用一个基本代码库支持多种物理N层架构，由此你的业务对象无肱饮食额外的代码来支持多种可能的部署情况，你需要实现支持对象在电脑间移动的那部分少量代码会被封装在框架中，这使得业务开发人员可以把精力全部集中在业务逻辑的开发上面。
以上是自己感觉很有意义的几段话，在此分享给大家，此框架确实很牛*。
因为自己能力有限，所以开发酷易化妆品商城（www.koyee.net）站花了不少的精力和时间，也学习了不少，有兴趣的朋友可以提出宝贵意见，以后一段时间会把过程中遇到的问题和学到的开发技巧写下来和大家一块分享，同时也遗留了许多的问题还要请教大家，也希望有学习或正在使用csla.net框架的朋友多帮忙一下，可以加QQ：496195435