数据层一般会给人带来一些困扰，在于其定位不准确。聚合Model的工作也可以放在逻辑层做，但会导致逻辑层变重，经常出现大段晦涩代码。因此我的建议是保留Model聚合层，尽管会导致工作量的略微增加，但却可以使代码逻辑更加清晰，即每一层都只做自己该做的事。
数据层可以不存在的理由在于逻辑层的业务聚合层已经做了类似的事。但区别在于，业务聚合层是以业务流程来划分的，而数据层则是更为细分的DB层上的聚合。
举个简单的例子，业务中经常会涉及到活动，一方面活动有自己的各类配置，比如规则、奖励、周期等，一方面活动又和用户、订单相关，因此你的数据库中至少需要两张表来储存活动相关的数据，activity表来储存活动配置，activity_tracking表来储存活动预订单的关系等，你的model层也会相应出现Activity和ActivityTracking对象。数据层的作用就在于此：将DB层中的多个同一抽象的model类聚合到一起，这样，逻辑层中将只会引用一个Activity的数据类。如果没有数据层，逻辑层中将引用这两个model层，并经常会在一个函数内对两个model进行操作，在业务逻辑复杂的情况下，逻辑层将变得臃肿不堪。
这里要注意逻辑层聚合和数据层聚合的区别。Activity和ActivityTracking虽然是两张表，但都记录着活动相关的数据，因此可以聚合到一个大专栏 Python Web 基础向（四） 浅谈数据层laintext highlighter-rouge">Acticity数据类中。而在活动的业务层中，聚合的范围则要大得多，可能会对用户、账户、余额、等级等多方面的东西都有操作，这是活动这一业务所决定的（之后会提到）。
# data/student.py
from my_project.models import auto_commit
from my_project.models.student import StudentModel
class Student(object):
@auto_commit
def insert_student(self, student):
return StudentModel.insert(student)
@auto_commit
def update_student(self, student):
return StudentModel.update(student)
def mget_student_with_id(self, student_id):
return StudentModel.mget_student_with_id(student_id)
# ...
(End)