简单数据库模型

时间:2009-08-30 21:45:33

标签: php oop model

我没有太多使用框架或任何东西的经验,所以这让我没有使用模型(MVC)的经验。目前我对使用框架毫无兴趣。我正在一个网站上工作,我正在尝试模拟一些对象,但我不确定我应该如何设计这个类。

例如,现在我有一个有一些公共成员的课程,可以直接访问。我已经开始原型化一些功能(选择,删除,更新),但我不确定

  1. 如果这些功能应该是静态的
  2. 如果这些函数应该接受参数或使用类成员
  3. 如果这些功能甚至存在于他们当前的状态
  4. 如果我想要的整个概念是正确的做法
  5. 我似乎无法在interwebs上找到关于如何创建模型类的任何提示。

5 个答案:

答案 0 :(得分:2)

如果您正在使用工厂类,则所有谓词通常都是实例方法,并且工厂将使用某种DB会话进行实例化。

如果动词是实体类的成员,则select通常是静态方法,而update通常是实例方法,而delete通常是双向定义的(IE:delete(recordID)entity.delete()

整个概念是正确的,但你会做错的。期。制作这样的可扩展模型比人们可以花费更多的时间和精力。我知道你对使用框架没兴趣,但你应该这样做。

答案 1 :(得分:2)

我的问题推断是,这是一个低调的项目,你有足够的灵活性,你的老板/客户/老师,你可以随心所欲地建立它。记住这一点,这是我在研究这个问题时会想到的。

如果MVC对你来说是一个新概念,那么测试驱动开发几乎肯定也是外星人。但是,我在做这件事时首先明白了对OOP的真正理解,所以我建议你试一试。首先针对您的模型类编写一些简单的单元测试将引导您完成如何使用这些模型类的练习。如果您不是TDD纯粹主义者,您将使用每个对象(或对象组)的外部API,这将有助于指导内部设计。查看PHPUnit开始使用,因为文档中也有一些很好的例子。

我认为TDD方法会引导您得出以下结论:

  1. 可能不是。静态数据/方法通常仅在您绝对需要某个副本时才有用。我发现在Web应用程序中,除了像DB这样的资源连接外,这种情况很少发生。
  2. 这取决于功能的作用。请记住,使用局部变量意味着副作用或对象状态的变化。如果您需要操作的数据不应更改整个对象的状态,请使用参数并返回值。测试这些方法也更容易。
  3. 再一次,为这些函数编写测试,说明如何在应用程序中使用它们,这将导致您以某种方式得出关于是否需要它们或者它们是否设计正确的结论。不要害怕改变它们。
  4. 绝对。如果你不至少推出一次自己的实现,你还会对MVC感到满意吗?事实上,在转向更专业的框架之前,最好先掌握实际经验。这样,您就会理解为什么框架的概念和约定是它们的方式。
  5. 哦,你发现模型类的缺乏清晰度,可能是因为它是你应用程序中最经常定制的部分。这是您的数据模型和域逻辑,因此很多都是特定于案例的。不过,最好的资源是恕我直言,马丁福勒,其优秀的企业应用程序架构模式详细介绍了如何以及为什么用一种模式或另一种模式设计一组特定的“模型”类。这是online pattern library - 显然这本书更详细。

    希望有所帮助。

答案 2 :(得分:1)

使用PHP时,我认为设计面向对象的模型增加了额外的工作而几乎没有什么好处 - 即使在查看大型框架时,通常只使用可以从结果集中获得的关联数组(参见f.ex.fultipradigm方法) Zend MVC)。

虽然对象关系映射在像Java这样的强类型语言中更为成熟,但PHP也已经有了工具(f.ex。Doctrine)。如果面向面向对象的模型是你想要的,你可以检查它,但要注意OR映射有它自己的严重问题,并且在PHP中可能没什么用处(还没有用动态语言自己尝试过)

对于大多数新开始的项目,选择一个好的框架通常是一种方法 - 它可以节省您的时间并推广最佳实践(当然,在一些学习时间之后,每个工具都有所不同)。在使用某些框架时,您应该始终尝试找出解决特定问题(如模型设计和数据访问)的框架/社区方法,然后再进行自己的实验。

答案 3 :(得分:0)

使用面向对象概念抽象数据访问的“正确”方法是很多人的热门话题。换句话说,有几种方法可以做到,并且没有“一种正确”的方式。

如果您正在认真升级现有应用程序,那么滚动您自己的工作效果最佳。这是因为你有一堆已经依赖于数据库的代码,你有一些必要的重构限制。它还教你如何抽象代码,因为大量的重构涉及删除(或减少)代码重复。完成此操作后,您将更好地了解数据模型层应如何工作。或者至少,应该按照你编程的方式工作。而且你会知道下次建立一个时不该做什么。 : - )

如果您正在开始一个新的代码库并且没有使用框架或对象层,但知道您需要构建一个,那么我能给出的最好的建议是愿意稍后构建一个,并重构代码适应那种情况。是的,这可能意味着您的应用程序将被重写几次90%。

编写一个对象抽象层是很困难的,你最终会得到密集的代码,这些代码对事物是相当防御的,并且不会冒险。但是一旦你有了它,你也会知道如何构建健壮的代码,因为它可能会被彻底调试。

答案 4 :(得分:-1)

  1. 不,因为静态方法难以测试
  2. 这取决于参数,生命周期等。如果没有看到某些代码,就无法回答。
  3. 没有
  4. OOP需要至少10年的经验才能更好地了解错误/正确/更好/更差。

    所以,如果你不是OOP专家,我建议不要浪费太多时间重新发明轮子,

    1. 使用众所周知的技术部分框架
    2. 为业务/功能部分创建类/框架。
    3. (1)将帮助您立即为经典技术部分(会话,数据库交互等)做好准备。将避免你犯其他人已经犯过的错误。

      (2)这是你的核心业务,它应该是“你的DNA”。

      此外,使用知名/良好的技术框架将使您阅读质量代码并帮助您取得进步。 (小心一些框架实际上质量很差)

      当您有足够的经验时,您将能够跳过技术框架部分并构建/定制您自己的...因为技术框架通常是邪恶的(它们用于太多目的)。 :)