最近我一直在从事一些 Perl 项目，我是一个非常新手的 Perl 程序员。我一直在尝试使用 DBIx::Class，到目前为止，我对它的灵活性和易用性非常满意。不过我很好奇。我来自 .NET 背景，似乎我们花了很多时间在一定程度上抽象我们的 DAL。对于像 Perl 这样的语言，这是一个好主意吗？
我想尽快实现的是能够开始模拟我的 DAL，这样我就可以为任务编写单元测试。现在虽然我正在努力解决应用程序的整体结构和设计应该如何？
【问题讨论】：
标签： perl orm data-access-layer
Re: ORM 在应用程序中的关系...
希望这是您正在寻找的答案...
对于“脚本”世界中的大多数 Web 应用程序框架（即 perl、ruby、python、php），大部分时间我都看到了在 ORM 对象级别实现的业务逻辑。例如。在 Rails 应用程序中，它位于 ActiveRecord 级别；如果您使用的是DBix::Class，它将处于Result-class 级别。
更具体地说，在DBIx::Class 的情况下，如果您有一个名为VENDOR 的表，则会有一个名为MySchema::Result::Vendor 的类，它表示表VENDOR 中的一行。只需将您的业务方法添加到此类。
这种方法的一个缺点是它将您的业务逻辑与 ORM 类联系起来，这会使（单元）测试更加困难。对此的一种解决方案是使用轻量级数据库进行单元测试（即 SQLite），而像 DBIx::Class 这样的 ORM 将有助于在两者之间进行切换。当然，如果您依赖 SQLite 中未实现的 SQL 功能，这将不起作用。
另一种方法是将您的业务逻辑方法放入 Moose 角色中。然后这些方法可以组合到 DBIx::Class Result 类或模拟对象中进行测试。如果您愿意，我可以举例说明。
上面的一个重要假设是您的业务对象 = 数据库中的一行。如果不是这种情况（即您的业务对象跨越多个表），那么您可能希望创建一个“shell”或容器对象，它具有每个组成 ORM 对象的实例成员。幸运的是，Moose 有一个很好的方法来委派方法（搜索 Moose delegation 和实例成员声明的 handles 属性），因此从两个或多个 ORM 对象中创建一个复合业务对象相对容易。如果你愿意，我可以再举一个例子。
HTH
【讨论】：
很久以前，我曾经在 web 的 perl 项目中工作过。但是在使用了 Django 之类的东西之后，perl 的 DBI 等工具现在在我看来相当初级和过时。例如，看一下 django ORM，它非常优雅且使用起来非常高效，如果您的查询过于复杂或 ORM 妨碍您，您可以绕过它...
这些天我会为这类项目使用 python 或 ruby。 对于一个衬里，小文本解析或系统管理员的东西，我仍然喜欢使用小的 perl sn-ps。但是这些天我更喜欢 DRY 而不是 TMTOWTDI 代码。
【讨论】：