实体类和业务逻辑类应不应该分开？在线等~~~

Question

     最近在看工厂模式的一些资料，因为是菜鸟，所以不知道是否应该将这两个类区分开来请教各位高手解释的详细点是否应该把实体类和业务逻辑类分开呢？

Answer 1

在一般的项目里面，分开来比较好。因为 Entity Object 本身有可能被 ORM 去维护。当然也可以用 Extend Method 或者 Partial Class 来实现。主要看架构师的设计意图。

Answer 2

实体类和业务逻辑类分开呵呵，这问题问的好。我先不回答你的问题。我先来说我理解的东西1。项目需求实际是互相交叉的如同3D分子模型图的那种3维结构
2。我们实际根本没办法去真正描述这个3D模型图滴，所以只能采用3视图这样的平面结构去描述它
3。既然只能是用平面图或部分关系图描述，难免以管窥豹，挂一漏万。很难真正表示完整结构。横看成岭侧成山，即使是对于同一个模型，不同的业务需求他的描述也不同。so，结果出来了。请lz告诉，你如果把实体和方法逻辑做在一块，能否真真正正去描述所有的关系？
我认为这是很困难的，设计师和程序员心里都应该十分清楚，你是不可能去知道所有细节和变化滴，也是不能用1张平面图，就能把3d关系全表达出来于是乎有了下面几个常用的结构3层：层层递进去交差组织描述。
mvc：从不同视角去描述，从不同视角去控制
aop：分方面去描述，然后动态编制就像上次有人问3层是否和面对对象冲突，答案是实际不冲突。 面对对象是模型，而3层则是实现模型的过程手段和描述机制。必须要明白 “虚实之变”分析问题，抽象出模型------这是由实入虚
但是虚就是虚，他不是实，我们要把他落到实处，还是要分步骤，分情况的。分层，mvc，aop就是由虚到实的过程

Answer 3

是这样的。首先要明确你将程序规划成几层，目的是什么。假设你的程序分为三层。那么你需要两套接口：DAL->BLL的接口，和BLL->UI的接口。很明显，你在业务逻辑层多加一个方法，并不需要修改它和 DAL 之间的接口。另外，三层引入了很多弊端，比如增加程序的复杂度，这个就需要你权衡了。对于绝大多数程序，业务逻辑都还在不断变更，分层越多，复杂程度会急剧增长。这就是为什么多层根本就不是一个正确的做法。

Answer 4

“你在业务逻辑层多加一个方法，并不需要修改它和 DAL 之间的接口。”
但是我需要修改应用层的接口呀对吗？

Answer 5

现在是这样，我在数据访问类AnserTable里多加了个方法，那是否也需要在这个访问类的接口上多加个成员呢？