我今天在cgiapp邮件列表上阅读了来自几位核心开发人员的关于开发一本关于CGI::Application的帖子。其中，有几个人提到它可能/应该以CGI::App和一些经常使用的模块为中心。其中一个模块是Class::DBI。
我看了看CPAN上的Class::DBI，它看起来非常棒，同时也可能太抽象了。基本上，您创建了许多包和/或包，一个用于您将在您的应用程序中使用的每个表，一个用于建立您的基本连接。然后，每个包创建一个连接的对象实例，并定义一些属性：表的名称、您将使用的列，以及它与其他表的关系（has_a（col_name=>'Package::Name');has_many(col_name=>'Package::Name');might_have(col_name=>'Package::Name');)等
然后您在脚本中使用您需要的模块/包，然后您可以使用面向对象的符号来执行插入行、更新行、搜索表、选择行等操作。它看起来相当自然。
我喜欢这样的数据抽象概念。但是，我看到了几个问题：
- 我不喜欢每桌一个套餐的想法；这变得如此抽象以至于使开发停滞不前，尤其是在初始开发期间。但是，一旦开发足够先进，我就可以看到这样做，特别是对于大型项目；它可以大大简化许多常规DBI调用。
- 我喜欢使用SQL。如果我需要调试为什么当我与数据库交互时有些东西不工作，我想对语言有绝对的控制权。抽象化SQL意味着我没有那种可以帮助我调试的细粒度控制。
所以，现在，我会坚持使用直接DBI……。但这是一个有趣的探索途径。
