领域逻辑与 SQL

事务脚本

事务脚本是我在 P of EAA 中为处理请求的程序化风格而创造的模式名称。在这种情况下，该过程读取它可能需要的所有数据，然后在内存中进行选择和操作，以确定需要哪些月份。

def cuillen_months name
  customerID = find_customerID_named(name)
  result = []
  find_orders(customerID).each do |row| 
    result << row['date'].month if cuillen?(row['orderID'])
  end
  return result.uniq
end

def cuillen? orderID
  talisker_total = 0.dollars
  find_line_items_for_orderID(orderID).each do |row|
    talisker_total += row['cost'].dollars if 'Talisker' == row['product']
  end
  return (talisker_total > 5000.dollars)
end

这两个方法，cuillen_months 和 cuillen?，包含领域逻辑。它们使用许多“查找器”方法向数据库发出查询。

def find_customerID_named name
  sql = 'SELECT * from customers where name = ?'
  return $dbh.select_one(sql, name)['customerID']
end

def find_orders customerID
  result = []
  sql = 'SELECT * FROM orders WHERE customerID = ?'
  $dbh.execute(sql, customerID) do |sth|
    result = sth.collect{|row| row.dup}
  end
  return result
end

def find_line_items_for_orderID orderID
  result = []
  sql = 'SELECT * FROM lineItems l WHERE orderID = ?'
  $dbh.execute(sql, orderID) do |sth|
    result = sth.collect{|row| row.dup}
  end
  return result
end

在许多方面，这是一种非常简单的方法，特别是它在使用 SQL 方面非常低效——需要多次查询来提取数据（2 + N，其中 N 是订单数量）。现在不要太担心，我将在后面讨论如何改进它。相反，专注于方法的本质：读取所有需要考虑的数据，然后循环遍历并选择所需的数据。

（顺便说一下，上面的领域逻辑是那样做的，以便于阅读——但这并不是我认为是惯用的 Ruby。我更喜欢下面的方法，它更多地利用了 Ruby 强大的块和集合方法。这段代码对许多人来说看起来很奇怪，但 Smalltalk 程序员应该会喜欢它。）

def cuillen_months2 name
  customerID = find_customerID_named(name)
  qualifying_orders = find_orders(customerID).select {|row| cuillen?(row['orderID'])}
  return (qualifying_orders.collect {|row| row['date'].month}).uniq
end

领域模型

对于第二个起点，我们将考虑一个经典的面向对象的领域模型。在这种情况下，我们创建内存对象，在本例中，它们反映了数据库表（在实际系统中，它们通常不是完全的镜像。）一组查找器对象从数据库加载这些对象，一旦我们在内存中有了这些对象，我们就在它们上运行逻辑。

我们将从查找器开始。它们将查询猛击到数据库并创建对象。

class CustomerMapper
  def find name
    result = nil
    sql = 'SELECT * FROM customers WHERE name = ?'
    return load($dbh.select_one(sql, name)) 
  end
  def load row
    result = Customer.new(row['customerID'], row['NAME'])
    result.orders = OrderMapper.new.find_for_customer result
    return result
  end
end

class OrderMapper
  def find_for_customer aCustomer
    result = []
    sql = "SELECT * FROM orders WHERE customerID = ?" 
    $dbh.select_all(sql, aCustomer.db_id) {|row| result << load(row)}
    load_line_items result
    return result
  end
  def load row
    result = Order.new(row['orderID'], row['date'])
    return result  
  end
  def load_line_items orders
    #Cannot load with load(row) as connection gets busy
    orders.each do
      |anOrder| anOrder.line_items = LineItemMapper.new.find_for_order anOrder
    end
  end
end

class LineItemMapper
  def find_for_order order
    result = []
    sql = "select * from lineItems where orderID = ?"
    $dbh.select_all(sql, order.db_id) {|row| result << load(row)}
    return result
  end
  def load row
    return LineItem.new(row['lineNumber'], row['product'], row['cost'].to_i.dollars)
  end
end

这些加载方法加载以下类

class Customer...
  attr_accessor :name, :db_id, :orders
  def initialize db_id, name
    @db_id, @name = db_id, name
  end

class Order...
  attr_accessor :date, :db_id, :line_items
  def initialize (id, date)
    @db_id, @date, @line_items = id, date, []
  end

class LineItem...
  attr_reader :line_number, :product, :cost
  def initialize line_number, product, cost
    @line_number, @product, @cost = line_number, product, cost
  end

确定 cuillen 月份的逻辑可以在几个方法中描述。

 
class Customer...
  def cuillenMonths
    result = []
    orders.each do |o|
      result << o.date.month if o.cuillen?
    end
    return result.uniq
  end

class Order...
  def cuillen?
    discountableAmount = 0.dollars
    line_items.each do |line| 
      discountableAmount += line.cost if 'Talisker' == line.product
    end
    return discountableAmount > 5000.dollars
  end

此解决方案比事务脚本版本更长。但是，值得指出的是，加载对象的逻辑和实际的领域逻辑更加分离。对这组领域对象的任何其他处理都将使用相同的加载逻辑。因此，如果我们正在执行许多不同的领域逻辑，加载逻辑的努力将被摊销到所有领域逻辑中，这将使其不那么成为问题。这种成本可以通过 元数据映射 等技术进一步降低。

同样，有很多 SQL 查询（2 + 订单数量）。

SQL 中的逻辑

对于前两个，数据库几乎被用作存储机制。我们所做的只是请求特定表中的所有记录，并进行一些非常简单的过滤。SQL 是一种非常强大的查询语言，可以做比这些示例中使用的简单过滤更多的事情。

充分利用 SQL，我们可以将所有工作都放在 SQL 中

def discount_months customerID
  sql = <<-END_SQL
  SELECT DISTINCT MONTH(o.date) AS month
    FROM lineItems l 
      INNER JOIN orders o ON l.orderID = o.orderID 
      INNER JOIN customers c ON o.customerID = c.customerID
    WHERE (c.name = ?) AND (l.product = 'Talisker')
    GROUP BY o.orderID, o.date, c.NAME
    HAVING (SUM(l.cost) > 5000)
  END_SQL
  result = []
  $dbh.select_all(sql, customerID) {|row| result << row['month']}
  return result
end

虽然我将此称为复杂查询，但它只是与前面示例中简单的 select 和 where 子句查询相比比较复杂。SQL 查询可以比这个查询复杂得多，尽管许多应用程序开发人员会回避像这样简单的查询。

可理解性

SQL 通常被视为一种特殊的语言，应用程序开发人员不需要处理它。事实上，许多数据库框架喜欢说，通过使用它们，您可以避免处理 SQL。我一直觉得这是一个奇怪的论点，因为我一直对中等复杂的 SQL 比较熟悉。然而，许多开发人员发现 SQL 比传统语言更难处理，许多 SQL 习语对于除 SQL 专家以外的所有人来说都很难理解。

一个好的测试是查看这三种解决方案，看看哪一种使领域逻辑最容易理解，从而也最容易修改。我发现领域模型版本，它只有几个方法，是最容易理解的；很大程度上是因为数据访问是分离的。接下来，我更喜欢 SQL 版本而不是内存中的事务脚本。但我相信其他读者会有不同的偏好。

如果大多数团队成员对 SQL 不太熟悉，那么这是一个将领域逻辑与 SQL 分开的理由。（这也是考虑培训更多人员学习 SQL 的一个理由 - 至少要达到中等水平。）这是一种需要考虑团队构成的情况 - 人员会影响架构决策。

避免重复

我遇到的最简单但最强大的设计原则之一是避免重复 - 由 Pragmatic Programmers 称为 DRY（不要重复自己）原则。

为了考虑 DRY 原则在这种情况下，让我们考虑此应用程序的另一个需求 - 一个特定月份客户订单列表，显示订单 ID、日期、总成本以及该订单是否符合 Cuillen 计划的合格订单。所有这些都按总成本排序。

使用领域对象方法来处理此查询，我们需要在订单中添加一个方法来计算总成本。

class Order...
  def total_cost
    result = 0.dollars
    line_items.each {|line| result += line.cost}
    return result
  end
 

有了它，就可以轻松地打印订单列表。

class Customer
  def order_list month
    result = ''
    selected_orders = orders.select {|o| month == o.date.month}
    selected_orders.sort! {|o1, o2| o2.total_cost <=> o1.total_cost}
    selected_orders.each do |o|
      result << sprintf("%10d %20s %10s %3s\n",  
	o.db_id, o.date, o.total_cost, o.discount?)
    end
    return result
  end
 

使用单个 SQL 语句定义相同的查询需要一个相关子查询 - 一些人觉得它很令人生畏。

 def order_list customerName, month
  sql = <<-END_SQL
     SELECT o.orderID, o.date, sum(li.cost) as totalCost,
            CASE WHEN
              (SELECT SUM(li.cost)
                 FROM lineitems li
                 WHERE li.product = 'Talisker' 
                   AND o.orderID = li.orderID) > 5000 
               THEN 'Y' 
               ELSE 'N' 
            END AS isCuillen
       FROM  dbo.CUSTOMERS c 
         INNER JOIN dbo.orders o ON c.customerID = o.customerID 
         INNER JOIN lineItems li ON o.orderID = li.orderID
       WHERE (c.name = ?) 
         AND (MONTH(o.date) = ?) 
       GROUP by o.orderID, o.date
       ORDER BY totalCost desc 
  END_SQL
  result = ""
  $dbh.select_all(sql, customerName, month) do |row|
      result << sprintf("%10d %20s %10s %3s\n", 
			row['orderID'], 
			row['date'], 
			row['totalCost'],
			row['isCuillen'])
  end
  return result
end

不同的人对这两个哪个更容易理解会有不同的看法。但我在这里咀嚼的问题是重复问题。此查询重复了原始查询中的逻辑，该查询只给出月份。领域对象方法没有这种重复 - 如果我想要更改 Cuillen 计划的定义，我只需要更改 cuillen? 的定义，所有使用都会更新。

现在，在重复问题上贬低 SQL 是不公平的 - 因为您也可以在丰富的 SQL 方法中避免重复。诀窍，正如数据库爱好者必须急于指出，是使用视图。

为了简单起见，我可以定义一个名为 Orders2 的视图，它基于以下查询。

  SELECT  TOP 100 PERCENT 
               o.orderID, c.name, c.customerID, o.date, 
               SUM(li.cost) AS totalCost, 
               CASE WHEN
                     (SELECT SUM(li2.cost)
                        FROM lineitems li2
                        WHERE li2.product = 'Talisker' 
                          AND o.orderID = li2.orderID) > 5000 
                  THEN 'Y' 
                  ELSE 'N' 
               END AS isCuillen
   FROM dbo.orders o 
     INNER JOIN dbo.lineItems li ON o.orderID = li.orderID 
     INNER JOIN dbo.CUSTOMERS c ON o.customerID = c.customerID
   GROUP BY o.orderID, c.name, c.customerID, o.date
   ORDER BY totalCost DESC

我现在可以使用此视图来获取月份和生成订单列表。

def cuillen_months_view customerID
  sql = "SELECT DISTINCT month(date) FROM orders2 WHERE name = ? AND isCuillen = 'Y'"
  result = []
  $dbh.select_all(sql, customerID) {|row| result << row[0]}
  return result
end

def order_list_from_view customerName, month
  result = ''
  sql = "SELECT * FROM Orders2 WHERE name = ? AND month(date) = ?"
  $dbh.select_all(SQL, customerName, month) do |row|
      result << sprintf("%10d %10s %10s\n", 
			row['orderID'], 
			row['date'], 
			row['isCuillen'])
  end
  return result
end

视图简化了这两个查询，并将关键业务逻辑放在一个地方。

似乎人们很少讨论使用这种视图来避免重复。我看到的关于 SQL 的书籍似乎没有讨论做这种事情。在某些环境中，由于数据库和应用程序开发人员之间的组织和文化差异，这很困难。应用程序开发人员通常不允许定义视图，而数据库开发人员形成了一个瓶颈，阻止应用程序开发人员完成这种视图。DBA 甚至可能拒绝构建仅供单个应用程序使用的视图。但我的观点是，SQL 应该像其他任何东西一样得到同等的关注。

封装

封装是面向对象设计的一个众所周知的原则，我认为它也适用于通用软件设计。本质上，它说一个程序应该被分成模块，这些模块将数据结构隐藏在过程调用的接口后面。这样做是为了允许您更改底层数据结构，而不会在整个系统中造成大的连锁反应。

在这种情况下，问题是如何封装数据库？一个好的封装方案将允许我们更改数据库模式，而不会导致应用程序中进行痛苦的编辑。

对于企业应用程序，一种常见的封装形式是分层，我们努力将领域逻辑与数据源逻辑分离。这样，当我们更改数据库设计时，处理业务逻辑的代码就不会受到影响。

领域模型版本是这种封装的一个很好的例子。业务逻辑只在内存对象上工作。数据如何到达那里是完全分离的。事务脚本方法通过查找方法进行了一些数据库封装，尽管数据库结构通过返回的结果集更明显地显示出来。

在应用程序世界中，您可以通过过程和对象的 API 实现封装。SQL 等效于使用视图。如果您更改了一个表，您可以创建一个支持旧表的视图。这里最大的问题是更新，更新通常无法通过视图正确完成。这就是为什么许多商店将所有 DML 包裹在存储过程中。

封装不仅仅是支持对视图的更改。它还与访问数据和定义业务逻辑之间的区别有关。使用 SQL，这两个可以很容易地模糊，但您仍然可以进行某种形式的分离。

例如，考虑我上面定义的视图以避免查询中的重复。该视图是一个可以沿数据源和业务逻辑分离线拆分的单个视图。数据源视图看起来像这样

   SELECT o.orderID, o.date, c.customerID, c.name, 
          SUM(li.cost) AS total_cost,
          (SELECT SUM(li2.cost)
             FROM lineitems li2
             WHERE li2.product = 'Talisker' AND o.orderID =li2.orderID
           ) AS taliskerCost
      FROM  dbo.CUSTOMERS c 
        INNER JOIN dbo.orders o ON c.customerID = o.customerID 
        INNER JOIN dbo.lineItems li ON li.orderID = o.orderID
      GROUP BY o.orderID, o.date, c.customerID, c.name

然后，我们可以在其他更关注领域逻辑的视图中使用此视图。以下是一个指示 Cuillen 资格的视图

      SELECT orderID, date, customerID, name, total_cost, 
             CASE WHEN taliskerCost > 5000 THEN 'Y' ELSE 'N' END AS isCuillen
        FROM dbo.OrdersTal

这种思维方式也可以应用于我们将数据加载到领域模型中的情况。之前我谈到过如何通过将 Cuillen 月份的整个查询替换为单个 SQL 查询来处理领域模型的性能问题。另一种方法是使用上述数据源视图。这将允许我们保持更高的性能，同时仍然将领域逻辑保留在领域模型中。只有在必要时才使用 延迟加载 加载行项目，但可以通过视图引入合适的摘要信息。

使用视图，或者实际上是存储过程，只能在一定程度上提供封装。在许多企业应用程序中，数据来自多个来源，不仅仅是多个关系数据库，还包括遗留系统、其他应用程序和文件。事实上，XML 的增长可能会看到更多数据来自通过网络共享的平面文件。在这种情况下，真正的完全封装只能通过应用程序代码中的一个层来完成，这进一步意味着领域逻辑也应该驻留在内存中。

数据库可移植性

许多开发人员回避复杂 SQL 的一个原因是数据库可移植性问题。毕竟，SQL 的承诺是它允许您在众多数据库平台上使用相同的标准 SQL，从而可以轻松地更改数据库供应商。

实际上，这始终是一个有点模糊的问题。实际上，SQL 大部分是标准的，但到处都有各种各样的陷阱。但是，小心谨慎，您可以创建 SQL，它在数据库服务器之间切换时不会太痛苦。但要做到这一点，您会失去很多功能。

关于数据库可移植性的决定最终取决于您的项目。如今，这已经不像以前那么重要了。数据库市场已经洗牌，大多数地方都属于三大阵营之一。公司通常会对他们所在的阵营有强烈的承诺。如果您认为由于这种投资，更改数据库非常不可能，那么您不妨开始利用您的数据库提供的特殊功能。

有些人仍然需要可移植性，例如提供可以安装并与多个数据库交互的产品的人员。在这种情况下，反对将逻辑放入 SQL 的论据更强，因为您必须非常小心地使用哪些部分的 SQL。

可测试性

可测试性不是在关于设计讨论中经常出现的话题。测试驱动开发 (TDD) 的一个好处是，它重新燃起了可测试性是设计的重要组成部分的观念。

SQL 中的常见做法似乎是不进行测试。事实上，发现基本视图和存储过程甚至没有保存在配置管理工具中并不罕见。然而，完全有可能拥有可测试的 SQL。流行的 xunit 系列有很多工具可以用于在数据库环境中进行测试。诸如测试数据库之类的 演化数据库技术 可用于提供与 TDD 程序员享受的非常相似的可测试环境。

主要影响因素是性能。虽然直接 SQL 在生产中通常更快，但如果数据库接口设计得可以将实际数据库连接替换为 服务存根，那么在内存中运行业务逻辑测试可能会快得多。