对ActiveRecord的评论

ActiveRecord的主要优点是一个过渡模式，当你没法从失血一步走到充血模型，或者不大确定是否该这样做时，是一种比较好的选择
另外就算使用充血模式的复杂项目，还是会存在很多适合ActiveRecord的对象
我想当你ActiveRecord使用熟练之后思路应该会不大一样，选择范围会比较开阔

@怪怪
结构化设计和面向对象设计之间的话题太大了，这里大部分人用.net开发应该面向对象的倾向会多一些。不同开发语言的特长和最适用的开发模式、应用环境都不一样，要综合各家优点适用于各种场景也不大现实

我 理解你说的意思，各种方法论、实现方式都是力图解决后面的本质问题，回过头来这些本质问题的解决方法决不局限于单纯的某种方法论或实现方案，采用不同的视 角看问题，可能他们之间本身也是相通的。基于复杂度方面考量，我比较倾向于中庸之道，ActiveRecord是符合这种精神的

poor model->ActiveRecord->rich model这样一个路线走下去，很可能就是走上EJB的路子，以及对rich model优劣的讨论是否该回归poor model，不管是应用能力还是方法论水土不服带来的问题，在我看来复杂度过高就代表着不合适，或者得异常关注确信可以克服
另外 ActiveRecord并不妨碍poor model设计思想，甚至是基于RecordSet的结构化设计思想，并且的确可以带来编码上的便利性、一致性，尤其是对.net这个平台而言。而在的确 需要rich model的场景下也可以方便的应用。中庸之道的好处就是随时随地可以两边倒，面对各种需要处理的场景可以灵活运用，这是我认可的优点

FP我不大了解，原本结构化设计思想就是不错的方法，面向对象的流行和普及现在不少人已经看到了它不适应的状况，因此我比较怀疑FP是不是又走了另外一个极端，来一个大规模的运用遇到的问题可能不亚于面向对象方法。不过确实在某些方面能够运用一些FP的特性的确是好事情，正如在该使用面向对象、设计模式的场景它的确能够带来极大的优点

@怪怪
如果不是极尽所能的去利用面向对象的各种手段，应该不会碰到它的缺点

有很多人极力的挖掘面向对象的概念，去实现"复杂业务"和"扩展性"、"伸缩性"、"可靠性"、"维护性"，而另一手却高举"没有银弹"的旗帜
很多的设计者对业务设计的关注几乎为0，结果是研究透了设计模式、重构、面向对象等方法却还是做不出好项目、好产品，而对各种问题的本质却可以夸夸其谈

这样的场景下什么方法、思想都没用