不懂EES为何物的路过一下

@henry 同理，我们可能是设计方式上有所差异，不能说谁对谁错 每个人都有自己的理解，最终目标是解决问题

@光影传说 首先，这个框架的设计思想就是基于泛形的SOA或面向对象的框架。 面向对象主要的思想是封装和继承... 也是许是,我认为对使用者来说简单越好,如果不能继承就能方便调那就更简单了..不过设计这东西因人而异..我喜欢的方法不代表其他人喜欢,以上紧是我个人的观点.

@henry 首先，这个框架的设计思想就是基于泛形的SOA或面向对象的框架。 面向对象主要的思想是封装和继承。 BLService<T>主要是封闭了与数据库相关的常用操作和业务对象的常用处理模型，也就是些辅助的东东。如果不是与数据库相关的业务，完全可以不必从BLService<T>继承。 兄台所说的BLService不仅仅针对一个实体，可能还有account和setting 之类等信息，完全正确，这个框架里的数据本身就是层次型的，是完整意义上的领域模型。 User与account可以是一对多的关系，或者说聚合关系 类似 public class User { DataCollection<account> _accountCollection; public DataCollection<account> AccountCollection { get{return _accountCollection;} set{_accountCollection=value;} } } account 是属于User,但，account也是独立的，只是依赖User而已。 account 同样应该具备自己的操作，如果在BLService<User>里面直接操作account，基本上是违反了面向对象的设计理念，会造成复杂逻辑的难以维护。 我的框架与UML通常可以作映射的，通过分析通常能够把UML图映射到编码接口上去，框架的背后有一套完整的分析与设计的思想支持。如果画序列图，则从序列图上能够完整的反映出来。基本上可以做到分析设计与编码的分离，程序员A写的代码与B写的代码一样。 分析设计如何与框架进行映射的，在后面，我会陆续介绍的 我的理解可能有偏差，请指教

@光影传说 DB做的事情就是专于数据处理,他是提供给不同逻辑调用的.如果他本身不能很好的工作而是依赖于某些逻辑的设计,那这个设计是不是有点不合理呢? 我感觉BLService<T>是应该封装一些逻辑上的东西或辅助的东西如代理等,如果DB本身操作已经够方便了,BLService<T>是否有必要封装DB的工作而让他变得臃肿． BLService<T>这个Ｔ让人搞不懂，在实现应用中BLService不紧紧针对一个实体，如user，她有可能还有account,setting等信息．那这个时候BLService<T>似乎难以表达，难不成还要起个BLService<account>？这显然是不可能的account是否存在决定于user.

@henry 接受批评，很快就加入这个类在里面。其实，底层本来就有这样的一个类，只是没有开放出来。从最终达到的目的上，是完全一致的。 我只所以这样做，就是为了少写几行代码罢，基类里面还有此其他的函数，可以直接使用，在做相关处理的时候，就不需要关心这个函数是DB的还是自己写的了，只需要关心这个UserService这个类，如果不是这样，则需要把DB里面的很多常用函数再重写一遍，比较麻烦;如果在其他相关类里面直接用DB的函数，也可以，不过好像有点破坏了封装。 请指教

从楼主的想法来看,做这些继承约束实现的目的就是横向功能处理..说实话摆脱继承这个约束对使用者来说更方便简单. 对于基类封装简单化的功能其实起得作用不大,特别在数据访问方面. public virtual T FindById(String code) { return base.FindId(code); } 和 public virtual User FindById(String code) { return DB.FindId<User>(code); } 没有多大差别,但前者需要一个基类支持用起来就不太爽了.

@路过秋天 兄弟的做法耦合度太高了，对于处理分布式的时候不方便，可以考虑用 Util.GetFrom/SetTo 这样的方式，或许会更好一点，另外，日志可以不需要写在代码里面，用配置的方式，可能更灵活些。

@cdboy 非常感谢，从你那里我才知道了clsa。下午看了一下clsa，感觉在思想上与clsa有很多相似的地方，但是处理方式上，相差还是很多的。比如，级联方式处理机制方面，相差就非常大，但是目标是一致的。 在对象模型这一块也有一定的不同： [Serializable] [Csla.Server.ObjectFactory("DataAccess.OrderFactory, DataAccess")] public class Order : BusinessBase<Order> { public static PropertyInfo<int> IdProperty = RegisterProperty<int>(p => p.Id); public int Id { get { return GetProperty(IdProperty); } private set { SetProperty(IdProperty, value); } } public static PropertyInfo<string> CustomerNameProperty = RegisterProperty<string>(p => p.CustomerName); public string CustomerName { get { return GetProperty(CustomerNameProperty); } set { SetProperty(CustomerNameProperty, value); } } public static PropertyInfo<LineItems> LineItemsProperty = RegisterProperty<LineItems>(p => p.LineItems, RelationshipTypes.LazyLoad); public LineItems LineItems { get { if (!FieldManager.FieldExists(LineItemsProperty)) LoadProperty(LineItemsProperty, LineItems.NewList()); return GetProperty(LineItemsProperty); } } protected override void AddBusinessRules() { BusinessRules.AddRule(new Csla.Rules.CommonRules.Required(CustomerNameProperty)); } private Order() { /* require use of factory methods */ } public static Order NewOrder() { return DataPortal.Create<Order>(); } public override Order Save() { return base.Save(); } } 从他们的Demo代码上面可以看的出来，他们用的是充血模型，而我用的是贫血模型，这种模型在处理服务器与客户端数据类型统一的时候，很难做。当然，这种模型也有自己的优点，在开始的框架里面也用过。 public static PropertyInfo<string> CustomerNameProperty = RegisterProperty<string>(p => p.CustomerName); public string CustomerName { get { return GetProperty(CustomerNameProperty); } set { SetProperty(CustomerNameProperty, value); } } 这种结构，对于后续的升级不方便，在上一个版本的框架里用过类似的方案，在当前版本的框架里面，已经去掉了。 不过，在权限处理方面，还是非常需要好好学习的，这一块我的框架里面，还没有处理。 我只是花了不太长的时间看了看，可能还有许多关键点我没有理解，有时间我再好好的看看 谢谢！

ORM的用法还是差不了多少的，和我去年写的框架相近，看用法： [code=csharp] UserListBean entity = new UserListBean(); entity.GetFrom(tbxUser_Name); entity.GetFrom(tbxFull_Name); entity.GetFrom(ddlUser_Type); entity.GetFrom(tbxPassword); entity.GetFrom(tbxEmail); entity.GetFrom(tbxCreateUser, CurrentUser.User_Name); entity.GetFrom(chbEnabled); entity.GetFrom(tbxRemark); if (GetID == 0) { entity.GetFrom(tbxPassword); if (Factory<UserListBean>.Instance.Add(entity)) { LogWrite.Write(LogModule.用户管理, LogType.增加, string.Format("添加用户[编号={0}]", entity.ID)); } } else { entity.GetFrom(lblID); if (Factory<UserListBean>.Instance.Update(entity)) { LogWrite.Write(LogModule.用户管理, LogType.编辑, string.Format("更新用户[编号={0}]", entity.ID)); } } [/code] 增加一个GetFrom与SetTo之后，代码质量有了质的飞跃，你也赶紧试试吧。

感觉有点像clsa

兄弟，您错了。沉了2年，不是说2年没有更新,中间还有过一个相对较大的升级。这次是比较大的升级，把老框架里很多的不足改掉了。比如，级联触发、数据绑定、远程对象与本地对象和数据库映射对象的统一,等等

两年时间里都没有更新过的东西，不敢用， 即使你是天下第一大牛，或者是.net之父， 一样的不用

?开源?还是?

由于那台服务器白天有客户需要用业务，所以白天关掉，晚上再开放下载，见谅

呵呵，好像不能下载呢

谢谢，henry,您说的很对，模板类在BL泛型的基类的基类里面已经有了，多一个主要是为了方便继承，把常用的东西放在后面，前面主要是放手写代码，方便管理。如果要放在一起，也是可以的。

楼主说的BL泛型基类,其实只能是个DAO模板.

学习了，楼主可否发个Email：hanyubao0341@163.com

看了楼主的文章,总体感觉DTO的作用是放在业务逻辑层和表现层之间的.处理表现层需要的数据.DTO则调用业务逻辑层方法进行所需数据的获取.

无法下载，

是否可以有发email

可以把dto class 贴出来吗？我还是不能够理解如何把dto绑定到gridview？

文件不能下载了，能不能再提供下载？！

写得很好！但是看得不是很懂。。。

你的DTO层 怎么没有说明啊 如果同时登陆的人数过多 需要排队系统 那是要放入哪里呢？ 不太明白了```你的缓存过程跟映射数据库的放到一起吗？ 不要分开来重载吗？

关于多数据源还是没弄明白，比如有两个数据源，一个是负责数据，一个是负责认证，那么应该采取什么方案呢？

@Jeffrey Zhao
从语言层次上、基础构架上说，.NET比JAVA只好不差。领域模型与业务逻辑与具体技术无关也没有错。对于Domain Model，Java能做到的.NET同样能够做到，这点是不用怀疑的。但是在整个面向Domain Model的设计思想上，是指这方面的差距。当然，主要是指这方面人的差距了，包括人的数量上等。
提供的框架的灵活性，业务层组织、服务层组织等这些方面，当然这些有经验的人都可以解决的都不成问题，但是这方面的人是太少了。是指这方面的差距。

@光影传说
我是从来不觉得.NET和Java领域间有什么差距——这两者有什么是本质区别吗？这些东西有什么东西是不能共享呢？虽然.NET和Java两种实现技术不同，但是领域模型业务逻辑等与具体技术明显无关，而且.NET的基础架构也比Java只会好不会差。比如就拿Domain Model来说，有什么Java领域做得到的.NET做不到？

园子里也没有分类之类，帖子很快就沉下去了，也没有人参与进来了。
_________________________________________________
这个是有点，不过关注的人都会订阅

@怪怪
你说的很有道理，有点突破性的东西，不是Fowler这样的人做出来的，这倒是真的，多是某一个人憋出来的。
原来从05年的充血型模型到现在的贫血型，其实，刚开始的时候，我根本不知道我用的是充血型，后来才知道的。不喜欢重复的没有意义的工作，做完了一个项目之后，就给这个充血型放血了。
只是感觉现在园子里都是发些纯技术的帖子，心里有点不爽，整天Linq TO SQL的用法等等。没有谈论怎么能把ORM与业务层怎么很顺的结合起来，关键还是在于业务层的组织关联，我没有见到多少。我总感觉这些比具体的实际应用要关键多了。
园子里也没有分类之类，帖子很快就沉下去了，也没有人参与进来了。

@光影传说
主要是， 你说的太粗啦， 让大家没法一窥全貌，所以不敢乱说。

这方面工作其实也非常耗精力的， 尤其是群策群力的目标往往无法达到。 这就是为什么大家会去读Martin Fowler的书的原因： 他们这些人专门拿时间来干这个， 虽然有时主观色彩浓厚， 也经常有不到家的地方， 但总比咱们工作做得到位。

另外就是他们能接触很多的人很多的项目， 你看Fowler经常说， 某某项目的情况怎么怎么样说明什么， 某某人对这事的意见是什么。 咱们缺乏的主要就是时间和透明性。总而言之， 网络上的讨论成本太高，误解也是经常出现的东西之一，无论是在内容上还是情绪上。

但是你发现没有， 那些稍微有点突破性的东西， 也不是Fowler这样的人做出的， 而往往就是某一个人自己那憋出来的。网络在这方面的作用， 更多的是帮助好的东西更快速的传播。

我觉得你站的位置特别好， 质疑自己才是咱们进步的动力。我唯一不满意的就是， 你这么寥寥几句， 就想引出砖头来；每个人理解最深的地方不一样， 比如我， 找不到合适的目标， 你叫我怎么扔砖头啊？

@怪怪
我的意思您可能理解偏了。我心里是有答案，这种组织方式也在两个项目中得到应用，但是用了，并不能代码就好，就合理。就如泛形用在此处，合理吗？我不能给出一个确切的答案，虽然可以工作。能用不是代表就好，至少我这种代码组织方式，还有很多不合理的地方。我估计想要理清楚这方面的人，应该不是我一个，就是想讨论一下，能不能找出更好的组织方式和规则，把理论与实践结合起来，而又不拘泥于理论。这方面那么多的东西，不能单靠一个人就能做好的，每个人都有思维定式，需要多人讨论才能打破，形成一种更好的更明了的业务层的代码组织方式。这才是我的本意，希望怪怪不要理解错了。

@光影传说
唉， 你要是心里已经有了自己的答案， 就按自己的答案做好了， 我从一开始就说了， 你的做法没啥问题，只是说如果你要是有疑问，有一些相关的东西你可以看看。 我那个帖子也只是刚开始收集， 毕竟大家都有自己的事情， 谁也没有太多的时间掰的太细。

比如“小生”那篇文章， 在我看来就非常画龙点睛， 把领域对象与系统边界首先区分开来， 其次把与持久化系统打交道的工作划归在了系统边界的控制器对象中，这就已经相当清晰了。这实际上也不是他提出的，而是已经形成理论而且是*得到较大范围验证*的设计和组织方式。

我觉得更具体的东西，只能咱们自己就自己的需要，自己去掌握。要是面面俱到的分析， 那得一大厚本书呢(甚至好多本书)，比如"小生"那篇文章的背景，就是基于DDD的理念对事情的看法和假设。有时间有兴趣，咱也只能自己去学习，大家讨论也只能点到为止而已。

如果说到业务层代码组织，话题就又大一圈，光把问题描述出来就要耗费咱们不少精力。比如你这篇文章描述不是很清楚，对"业务操作"这些词汇就没有很好的定义；我只是就我能理解的问题，做个提醒而已，也不是说就有能力把这个疑惑给解答了。

至于ORM什么的， 只是个人选择而已，也没有否定别人的意思；框架也是这样：MFC/ASP.NET，都是框架+代码生成的方式，没有说一定不合理。只是但凡一件事，都有第二个甚至更多个视角。设计模式的作者Gamma在几年前的访谈中就说过，从95年之后10来年的实践，他现在对这种方案和当年的一些说法持更谨慎的态度。

另外就是，代码生成能够做到的事，往往也会有另外一种非代码生成的等价或更好的解决方案，当然这话也不是我说的，只是我更多的相信和选择非代码生成这条路。

至于8/2原则之类， 也不是只有一种方式能实现不是？在我看来，更多的是区分哪些是核心复杂度。对于七零八碎的东西，八仙过海，更显其能呗～

@怪怪
我这里说的，并不完全是持久化与领域逻辑的关系。主要是针对业务层代码的组织，怎么样做，才能更清晰易懂，一个人写的代码另外一个人看起来不会产生阻力，当业务逻辑复杂的时候，能够容易把业务逻辑方便的组织起来，不会冗杂在一起。通过你的Track，也没有看到已经把“持久化与领域的关系”这个问题完全讨论清楚了，更别说业务层的代码组织了。
你说你不喜欢ORM，是因为制造了一大堆PO，那你不能通过别的方式处理，把能够隐藏的东西隐藏在后台处理，这也涉及到组织关系。
对于代码生成，代码生成只是辅助，代替人工工作，这些代码也只是个框架代码，人工要处理的就是在生成的代码上面加入逻辑。在程序里，核心业务的不是很多，超过20张表就比较少了。按80%与20%的原则，应该把80%的精力放在20%的核心业务上。

@光影传说
1. 关于持久化与领域的关系

这个问题，你顺着我的TrackBack进去， 里面引用了一篇园子里的兄弟的文章， 基本上把这些问题怎么看待说清楚了， 几句话的事情。

2. 关于ORM。

ORM和存储过程不冲突吧， 数据库性能， 这又是另一个话题了。 我不喜欢ORM，只是因为它制造了一大堆PO， 这种形式要么严重的影响其它方面的设计， 要么就是需要大量适配，无谓的浪费CPU和内存，同时也造成不少工作量。

更多的， ORM和我的审美严重冲突，虽然有时候不得不向现实妥协。

3. 代码生成

这个方面我无法说出来太多； 只是看不少大师都不把代码生成当成真正的解决方案。 我的看法是，代码生成很多时候是必要的， 其实如果是动态的生成类， 或者Emit， 还是代码生成（而且还是不安全的代码生成）。

我的想法是， 能用逻辑代替代码生成的， 就不用代码生成； 只有没办法的地方才用它。 我的体会是， “没有办法”也是相对的， 有的时候去年还没有办法的事， 今年就有办法了 :)

最后， 关于实用和理论之间的矛盾， 确实存在，有些人以解决当前问题为主(不解决不行啊)，有些人在根源上做出不断的尝试(即使是失败的尝试)； 没有什么矛盾， 分工不同而已。

@bmrxntfj
领域中的对象是否有主动型>>>>这个怎么解释啊？
业务逻辑需要多个对象交互，那就为其建个Service>>>不明白什么意思？

service就是服务，服务一般不会涉及到什么业务逻辑吧... 服务一般就是给
事务，给安全验证，类似的东东..

@zhangxd
对于些处用泛形实现，我刚开始也在考虑，到底应该不应该加，我现在也在考虑这个问题。
泛形重要就是强类型，此处加入泛形是为了处理继承问题。但是在现实中只用过有限几次。

对于CRUD，CRD是在Service的基类里实现的，R则是通过代码工具生成的。生成的代码与需要手工添加的代码用部分类分开存放，要手工写的基本上的业务逻辑的代码。对于通用查询，在基类里提供一个Protected的函数，根据情况进行公开。

基本的代码以生成为主。包括关联、数据类等、服务、注释等

@bmrxntfj
这样，你同样引用了两个对象。
在编码的时候，需要去分清，哪些是主动型的，哪些是需要多个对象交互的。
当是主动型的，放在Data类里面，但是如果是通过远程访问的，对于服务层同样要把这些主动型的动作公开出来。那么，服务层又要以另外的一种思想去考虑问题。当然，对于不需要分布的BS程序是可以的。如果应用服务器与Web服务器不在一台服务器上呢？
分清主动型这些操作还不如直接放在一个Service里面，两面相同的思维方式。没有必须转来转去，简单明了易懂，也是设计所要达到的。

我这里面，只谈些实际中遇到的问题，没有那么多的理论，一切为好用实用为原则，不会引经据典。都是实际中遇到的。

@怪怪
这是一个古老的话题呀，主要是看到园子里总是些纯技术方面的东西。另外，这方面的话题是个引子，这个讨论完，再出下一题，一层一层的来。
主要是讨论代码的组织、简单化。
您说CRUD不属于BL，但在很多情况下，CRUD却是组成这些业务逻辑的基础，这又怎么看呢？当然，也有些是虚属性(通过其他属性计算出来的)、不需要与持久层交互的规则，比如总金额＝单价×价格×数量等，要求单价必须在0~100之间等，这些是信息也可以写在Data里。
ORM我觉得，只是数据存取方式，也是为了减少人的工作量罢了，你就是直接用拼接字符串，也可以达到相似的效果。如果不用ORM，用存储过程？可能又会带来其他的问题，如果性能的瓶颈在数据库，又怎么办？

关于代码工具，如果没有代码工具，那么多的代码，总要人去写的，易出错，工作量大。前提是代码工具你自己是可控的。像集成开发环境的代码生成，我们是不可控的，还有其他的一些工具，生成的代码有其自己的规则，也算是不可控的。能生成为什么不生成呢？

>>>>>>>对于简单的基本逻辑通过基于泛形实现，并把对业务实体数据的CRUD操作放在单独Service 里，每一个Data都对应着一个Service。

这个累了点吧

有点意思

我觉得灵活最重要，做程序要坚持基本原则的基础上，来灵活应用才最好，
如果在类里写入逻辑，能够为你在其他地方省一大堆代码，我觉得很不错，我也是这么做的。
就比如我最近在算滞纳金一样，我在实体类里写了一点代码，就解决了，那些老程序员要写半天的代码，呵呵！
灵活很重要，不要拘泥一种形式！

感觉有点乱.不是太明白.

领域中的对象是否有主动型，有就把该操作放入其中。
业务逻辑需要多个对象交互，那就为其建个Service

你说的稍微有点简略，不过如果你指的业务操作是数据库相关操作的话：这个问题1年前干嘴仗的结果好像说的很清楚了。

CRUD这类操作不属于BL的范畴，应该放入边界对象里； 对象是否贫血， 要看对象是否真的存在自身的业务逻辑。那种认为相关数据操作应该在对象身上就更面向对象的说法，实际上是没真正学过这方面知识的人的一知半解。

不过大嘴Fowler的书里ActiveRecord等两个方式的一个表现出来的特征就是CRUD在对象上，这种设计很多时候也是行之有效的； 同时是不少ORM/半ORM工具箱所采取的做法之一(虽然我对ORM极端不感冒)。

只是ActiveRecord...，我有时候真想不通能给咱带来什么好处。难道Object.Delete()打起字来比较爽? 所以我个人觉得你这种做法很不错， 只是我不喜欢代码生成的方式 :P

同时，我认为如果是彻底贫血的对象， 可以好好考察一下它是否真有必要以确定为某一具体型别的对象的面目出现； 而不是反过来对该型别的对象缺乏操作耿耿于怀， 恨不得把所有和它沾边的事情都交给它负责。

有点意思，向LZ学习。

写得不错

好文，谢谢
www.netgou114.cn

很好，谢谢！

推荐：www.netgou114.cn

--引用--------------------------------------------------
光影传说: @orichisonic
兄弟是太看的起我了，我只是一个刚刚从部队转业3年的阿兵哥，由于喜欢软件，放弃了公务员选择了程序员，虽然年龄比较大，但是由于缺少在社会锻炼的黄金时光，现在只是在一个很小很小的公司打工，由于公司太小，真的不好意思说出来......

--------------------------------------------------------

不错，喜欢这样的人！有干劲，敢拼敢闯！！加油！祝你成功！！