感觉如果用三层模式的话，实体类要设计得很庞大
刚学asp.net，发现这个问题。

在三层模式里，实体类实际上是起到传递数据的作用。

在一些应用里，有多个表，是相互关联的。如果根据表来生成实体类，那么就是一个表一个类。
但是在界面显示的时候，却发现这个样子特别麻烦。比如在一个框里输入一个实体类（表A）的名称。假设表关联有表B的ID，表C的ID等等
为了要在界面把这些ID所代表的name都显示出来，必须到后台AJAX获取表B的实体类，表C 的实体类……，然后再使用表B.name， 表c.name来显示这个值。真累。

如果用view，那么又要创建这个view的实体类……啊真是烦死了。

于是只好把表A的实体类创建得特别大。这样的话，有些类实在是大得……为了性能，只好用N多个case语句，指明在什么条件下取某些字段。

各位大侠是怎么处理的？
------解决方案--------------------
商业做法爱用这些框架是因为这些框架都有Auto Generic code tool
------解决方案--------------------
一般都是用生成工具，生完再改。CodeSmith
------解决方案--------------------
codesimth，多设计些功能，在生成实体类的时候，就写好各种关联的字段和各种case语句。

没办法，程序大点，只要不出错，不影响性能，只能忍了。
------解决方案--------------------
其实，你可以把实体类分开来理解，一种是DTO,一种是Entity,DTO就是一个数据传输对象，你可以把你前台一个页面所有用到的数据都放进去，如果有引用(就像你说的A里面要引用B的字段，B里面要引用C的字段)，你可以这样：

class A

{

   int AId;

   //other

   B b;  //这里对B的引用

}



class B

{

   int BID,

   //other

}

在业务逻辑里面，你可以将A数据拿出来，如果有用到B数据，再将B数据拿出来,假如取出 的B的实体是b，那么你可以这样A a=new A();a.b=b; 返回的实体a里面可以通过 a.b 就可以去取B的数据，而不用ajax等方式来取。
   其次对于Entity,你可以理解就是表和实体的对照，这类实体可以用来做普通的操作，可通过工具生成。
   你还可以这么理解，DTO往返于页面和业务逻辑之间，以及业务逻辑和业务逻辑之间，Entity往返于数据库和数据访问层之间

   （描述不一定准确，但大概是这个意思，方便理解）