没搞明白的内容（概念）

Question

１．不明白实体层里面放的东西是什么，他有什么用？
２．对于三层结构开发在每个层应该放什么东西（最好详细些）

Answer 1

呵呵,果然是比较概念的东西..参考MSDN的例子先..1.掌握 ASP.NET 之路：自定义实体类简介
http://www.microsoft.com/china/msdn/library/webservices/asp.net/CustEntCls.mspx2.分层架构的例子:
http://www.microsoft.com/china/community/program/originalarticles/TechDoc/duwamish.mspx

Answer 2

我们的实体类只有实体，而没有包含关于实体的一些方法。实体类是贫乏的。一般来说，用实体类替换参数列表是为了统一接口，虽然各层代码还是需要改变，但接口不必改变了。当你公开一个public接口的时候，你可能不知道有多少人调用了你，一旦你是用参数列表的形式，那么就比较麻烦了，你一改接口，调用方都要改了，一些本来不需要改的代码也要改动了。而用了实体的话，这个问题是解决了，只有在需要的方法中，修改相应代码就行了。
业务逻辑、 数据访问和存储。 
对于三层之间，有一种提法将，数据访问层作为基类，将存储的方法写入其中，而具有其他业务逻辑和表示两层功能的类要由数据层继承。 
这样，感觉上对于系统是有一种整体感觉，但这样的设计方法，将软件的多层优势掩盖体现不出多层分布式在应用上分布的好处。既然提出了多层分布而且在实际应用中，三层结构的优势远大于C/S结构。因此应尽量做到此三层之间是相互独立。三层之间的信息传递用接口，并且应尽量减少他们之间的继承关系。对于此三层之外，我习惯在增加一个实体层。实体层内定义系统中存储实体，然而实体层并非将数据库中存储实体的所有字段全部定义，只定义需要的字段。在以后发现需要新增字段，再在实体层内增加相应字段的定义。实体层有可能被其他三层引用.而在其他层可以写相应的实体的操作。而我感觉对于数据的验证也可以将其的验证代码写在实体层。这样便于软件的修改和升级。

Answer 3

那对于里面的get 和set方法应该如何理解呢？

Answer 4

顶一下，想问问实体类里面的get和set是怎么回事？不理解为什么用它们？

Answer 5

using System;
abstract class Shape 
{
   public abstract double Area 
   {
      get;
      set;
   }
}class Square: Shape 
{
      public double side;      // Constructor:
      public Square(double s) 
      {
         side = s;
      }   // The Area property
   public override double Area 
   {
      get 
      {
         return side*side ; 
      }
      set 
      {
         // Given the area, compute the side
         side = Math.Sqrt(value); 
      }
   }
}class Cube: Shape 
{
      public double side;          // Constructor:
      public Cube(double s) 
      {
         side = s;
      }      // The Area property
      public override double Area 
      {
         get 
         {
            return 6*side*side;
         }
         set 
         {
            // Given the area, compute the side
            side = Math.Sqrt(value/6);
         }
      }
}public class MainClass 
{
   public static void Main()  
   {
      // Input the side:
      Console.Write("Enter the side: ");
      string sideString = Console.ReadLine();   
      double side = double.Parse(sideString);      // Compute areas:
      Square s = new Square(side);
      Cube c = new Cube(side);      // Display results:
      Console.WriteLine("Area of a square = {0:F2}",s.Area);
      Console.WriteLine("Area of a cube = {0:F2}", c.Area);       // Input the area:
      Console.Write("Enter the area: ");
      string areaString = Console.ReadLine();   
      double area = double.Parse(areaString);      // Compute sides:
      s.Area = area;
      c.Area = area;      // Display results:
      Console.WriteLine("Side of a square = {0:F2}", s.side);
      Console.WriteLine("Side of a cube = {0:F2}", c.side);
   }
}

Answer 6

在传统的C/S应用中，也存在着上述同样的问题，多层结构的应用正是在C/S 结构的基础上产生的，并且也扩展到了B/S应用开发领域。 即将应用划分为三层(可以有更多层，但三层最常见): 用户界面层，商业逻辑层，数据库层。 　　用户界面层负责处理用户的输入和向用户的输出，但并不负责解释其含义(出于效率的考虑，它可能在向上传输用户输入前进行合法性验证)，这一层通常用前端工具(VB，VC，ASP等)开发。　　商业逻辑层是上下两层的纽带，它建立实际的数据库连接，根据用户的请求生成SQL语句检索或更新数据库，并把结果返回给客户端，这一层通常以动态链接库的形式存在并注册到服务器的注册簿(Registry)中，它与客户端通讯的接口符合某一特定的组件标准(如COM，CORBA)，可以用任何支持这种标准的工具开发。
　
　　数据库层负责实际的数据存储和检索。 有了这样的结构，上面的问题迎刃而解:还是以考试系统中的合格标准为例，在客户端所有需要显示合格人员名单的地方，调用这样一个函数GetQualifiedList，至于这个函数如何编写，如何与数据库打交道，以至访问的是何种数据库都与其无关(你一定有过这样的经历，在一种数据库系统上运行得很好的SQL语句，有时换到另一种数据库系统上必须加以修改); 在中间层DLL中实现这个GetQualifiedList函数，如果用户对"合格"的定义变了，只需要修改这个函数就可以了，只要此函数的入口参数和返回内容不变，在客户端不需作任何改动。在这里，我们看到了面向对象编程的特性之一封装性的优点，而这一点在开发大型应用时尤其有用--我们可以把开发人员分成两组，一组负责开发界面层，另一组负责开发商业逻辑层，双方只要按照事先商定的函数接口，并行地开发就可以，而不必向从前那样，后面的工作必须等前面的工作完成后才能开始。当然，这样的开发模式需要很好的项目协调和文档作支持。 　　你也许会问，如果我把这些函数些在一个单独的文件中，再在需要调用的地方把它包含进来，不是同样能达到目的吗? 第一，这种方法效率不高，无论你把这些函数分散到多少个文件中，当你需要调用其中一个时，总会包含进一些实际上并不需要的函数，这无疑加重了服务器的负担，对服务器性能要求较高的Web应用尤其如此。 而DLL只在需要时才调入内存且只调入需要的函数，并且多个应用程序实例可以共享同一个DLL实例；第二，设想一个员工，有20个属性(工号，姓名，年龄，性别......)，现在给定某工号，要求返回此员工所有信息。此时如果单纯用函数，只能定义20个全局变量，在函数中改变这些变量值，或者定义一个有20个传参(by reference)参数的函数。显然，第一种方法很麻烦而一旦增加一个属性后一种方法就需要更改函数接口。而在一个对象里，既包含成员方法(即函数和过程)，也包括成员属性。如果我们采用对象的方法，则在函数中只需要改变对象的属性，在函数外可以直接引用改变了的对象属性值。 这种方法有些类似第一种方法，但1.属性值无需在函数外逐一说明；2.这些属性值只属于对象，与对象无关的代码不会无意地改变属性值；3.一旦对象被释放，这些值会被一起释放。