Question

我注意到我的所有模特看起来非常相似。他们中的大多数倾向于遵循一种模式，在这种模式中，它们是包含活动记录代码的方法集合，这些代码只是彼此之间的微小变化这是一个例子：

class Site extends CI_Model {

    public function get_site_by_id($id)
    {
        // Active record code to get site by id
    }

    public function get_sites_by_user_id($user_id)
    {
        // ...
    }

    // ...

    public function get_site_by_user_id_and_url_string($user_id, $url_string)
    {
        // ...
    }

    // Non active record methods and business logic
    // ...

}

这种方法对我来说很好，但我想知道是否有更优雅的解决方案。我似乎不应该每次需要以新的方式查找数据时创建一个新方法。这是常见做法还是我错过了重构这种方法的方法？

Answer 1

严格遵循您的请求，您可以在主模型类（CI_Model）和您的类（Site）之间添加一个中间类，类似于

class MyCommonMethodsClass extends CI_Model {
}

你可以在你的类（站点）中扩展它，同时将公共代码放在它上面。这样会起作用，并且可能在某种程度上“优雅”。事实上，最后你最终会添加你的基本crud，网站改编的动作。

现在，如果那是“干净”的话，那就是另一回事了。同样，严格来说，模型就是这样做的。它照顾普通和'先进'的吸气剂。是的，他们几乎总是倾向于在您的网站周围拥有相同的代码。问题在于，尽管在代码中看起来很好（代码较少），但在技术上却牺牲了业务逻辑和数据库之间的抽象。你是模范纯粹的还是实用的？

Answer 2

我认为这是意见问题，但我认为最佳做法是创建某种创建，检索，更新，删除（CRUD）模型，该模型执行许多基本的SQL函数，如GetID，UpdateByID，GetById等。

CRUD模型只能帮助您进行更多模块化查询。但是调用一个名为GetId的函数并传递一些参数而不是为每个表提供不同的函数是有意义的。

正如我所说，CRUD只能走得那么远。例如，有一个查询数据库用户表的函数来检查用户是否已经验证并且用户名＆amp;密码匹配。由于这是一个独特的而不是抽象的函数，它应该定义它自己的函数。

同样作为最佳实践，不应将逻辑和数据库访问混合在同一文件中。

Answer 3

通常的做法是使用不同的方法来处理这样的数据。 Single Responsibility Principal声明每个对象应该只做一件事，通过使多个方法获得非常具体的数据，您创建的数据非常易于维护且易于调试代码。

Answer 4

如果你有多个类提供基本相同的功能，那么这表明你的类层次结构可能有问题（所谓的“代码味道”）。如果他们有相似的互动，则表明他们在某种程度上相关。如果是这种情况那么很可能它们都应该从一个实现所有子类通用功能的公共超类继承，每个子类只是专门化超类的通用功能。

这种方法的优点是：

你不是在重复工作（SPOT，DRY）
与类交互的代码可以用更通用的方式编写，并且可以处理从超类继承的任何对象（替换）

Answer 5

我认为创建'基础'模型类以扩展其他模型没有任何问题。如果它坚固且经过良好测试，它可以让您的生活更轻松。一遍又一遍地创建相同的CRUD函数有什么意义？

这样做的另一个好处是，您可以拥有一个基础开发存储库，您可以克隆该存储库以启动所有新项目。

如果您需要一个如何执行此操作的示例，请查看我之前询问过的question。

您也可以对controllers进行相同操作。

我的模特看起来都一样

5 个答案: