Perl DAL设计问题

Question

最近我一直在研究一些Perl项目，我是一个非常新手的Perl程序员。我一直在用DBIx :: Class进行试验，到目前为止，我非常满意这种灵活性和易用性。我很好奇。我来自.NET背景，似乎我们花了很多时间在一定程度上抽象我们的DAL。用Perl这样的语言这是一个好主意吗？

我希望很快就能开始嘲笑我的DAL，因此我可以为任务编写单元测试。现在虽然我正在努力应用程序的整体结构和设计应该如何看待？

Answer 1

回复：应用程序中的ORM的关系......

希望这是你在“脚本”世界找...

对于大多数Web应用程序框架，这样回答的（即perl，ruby，python，php），大多数时候我已经看到了在ORM对象级别实现的业务逻辑。例如。在Rails应用程序中，它的级别为ActiveRecord;如果您使用的是DBix::Class，则该级别为Result。

更具体地说，在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

Answer 2

我以前很久以前在网站上的perl项目中工作。但是，在处理诸如Django之类的东西之后，perl的工具如DBI等现在对我来说看起来很简单而且过时。例如，看看django ORM，它的优雅和高效使用，如果您的查询太复杂或者ORM受阻，您可以绕过它...

这些天我会去蟒蛇或红宝石的那种项目。 对于一行，小文本解析或系统管理员的东西，我仍然喜欢使用小的Perl片段。但是现在我比DRTYTDI更多地使用了几行代码。