1 用一个例子来讲解一个问题，现在又一个库表hello,表内容如下：
id name
1 Null
2 Null
3 Null
4 Null
5 Null
hello表一共两个字段：id和name，name is null。
第一条SQL：SELECT COUNT(id) FROM hello; 查询结果：5，正确。
第二条SQL：SELECT COUNT(*) FROM hello; 查询结果：5，正确。
第三条SQL：SELECT COUNT(name) FROM hello; 查询结果：0，错误。
第四条SQL：SELECT COUNT(DISTINCT id,name) FROM hello;查询结果：0，错误。
2 第二条SQL和第三条SQL查询错误的原因：
2.1 COUNT(), MIN(), and SUM() ignore NULL values.
2.2 The exception to this is COUNT(*), which counts rows and not individual column values.
2.3 For example, the following statement produces two counts. The first is a count of the number of rows in the table, and the second is a count of the number of non-NULL values in the age column:
mysql> SELECT COUNT(*), COUNT(age) FROM person;
三层架构(3-tier application)通常意义上的三层架构就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。区分层次的目的即为了“高内聚，低耦合”的思想---摘自百度百科
MVC是模型(Model),视图(View)和控制（Controller)的缩写，其目的实现Web系统的职能分工。其中Model层实现系统中的业务逻辑，通常可以用JavaBean或EJB来实现；View层用于与用户的交互，通常用JSP来实现；Controller层是Model与View之间沟通的桥梁，它可以分派用户的请求并选择恰当的视图以用于显示，同时它也可以解释用户的输入并将它们映射为模型层可执行的操作---摘自百度百科
三层架构的学习是我们在第二次重构机房收费系统时采用的开发架构,其实更准确的说应该是学习三层的一种'分层'思想,之所以称为三层,是因为我们在机房收费系统中,主要将系统主要分为了三层,而真正的划分的话,我们还可以加上设计模式以及SQLHelper,层数的划分是可变的.
MVC是一种设计模式,是我们在B/S学习阶段开发web项目的一种开发模式，MVC开发模式也是为了帮助我们解耦，提供了一种分层的思想，只不过我们常说的三层架构更多的是应用在C/S项目上，MVC模式是应用在B/S项目上。如果真的要区分三层与MVC关系，可以说三层与MVC是父与子之间的关系，三层为父，MVC是子。
虽然三层与MVC都存在一种分层思想，但二者还是存在应用上的区别。下面这张图是在形式上将三层与MVC进行对应，将二者放在一起进行比较，并不是说三层与MVC一定要有明确的对应关系，而是更深刻的认识三层与MVC的区别。
PS：在后面的J2EE学习中，回顾学过的三层，更深刻的去认识，理解‘分层’将分层思想植入我们的代码设计中，培养一种分层，抽象的习惯。
领域逻辑用来表达业务概念，保证业务规则，存放业务数据和业务状态等。领域逻辑通常是通过领域模型中的对象来实现的，且这些对象并不知晓其持久化方式，不过数据仍旧被存储且行为也与相关的业务概念和规则保持一致。作为一个概念，强类型DataSet也可用来对领域进行建模。
虽然存储的技术细节将委托给基础设施完成，不过反映业务情况的状态将在这里控制并使用，领域逻辑这一层是业务软件的核心。
在有了软件需要实现的一系列操作之后，即可开始对应用逻辑进行建模。应用逻辑将组织业务对象和应用程序服务，以便满足表现层的需要。应用逻辑也叫应用层，这一层的职责对于保证业务非常重要，并负责与其他系统的应用层交互。这一层将保持简单，并不需要了解业务规则，只需要协调任务并将工作委托给下层中一系列协作的领域对象即可。
应用逻辑将包含处理问题的工作流，且实现于服务层中，与业务层分离开来。应用逻辑实现了用例，实现过程中使用到了领域逻辑所提供的功能。好的服务层应该是很简单的一层。
为什么在应用程序中需要有两种逻辑呢？这是因为应用逻辑很明显需要依赖于应用程序的用例和用户界面。若将这些逻辑放在领域模型中，那么领域模型中的类型自然不会有太好的重用性。也就是说，应用逻辑和领域逻辑的分隔是有代价的，主要为了处理复杂性。在一个程序中区分两种类型的逻辑并不是适用于所有情况的强制要求。
领域逻辑中的实体大多是独立的对象，对其他的实体没有太多的了解，实体中的交互（例如：创建、删除、或与其他实体执行工作）一般由服务层组织，并由领域逻辑管理。领域逻辑中实体可以直接交互的唯一情况将是实体之间存在逻辑上的上依赖，例如，Order于OrderDetail之间。