使用 Doctrine 抽象 CRUD 操作

发布于 2024-09-04 00:02:17 字数 999 浏览 2 评论 0原文

这个问题困扰了我很长一段时间,但现在我有必要找到答案。

我们正在使用 CodeIgniter 和 Doctrine 开发一个相当大的项目。

我们的应用程序有一个前端和一个管理区域,供公司检查/更改/删除数据。

当我们设计前端时,我们只是在控制器中使用了大部分 Doctrine 代码:

//In semi-pseudocode
function register()
{
  $data = get_post_data();

  if (count($data) && isValid($data))
  {
    $U = new User();
    $U->fromArray($data);
    $U->save();

    $C = new Customer();
    $C->fromArray($data);
    $C->user_id = $U->id;
    $C->save();

    redirect_to_next_step();
  }
}

显然,当我们去做管理视图时,代码重复开始了,考虑到我们处于“完成它”模式,所以它现在代码很臭膨胀。

我已经使用模型方法将很多功能(业务逻辑)移至模型中,但基本的 CRUD 不适合那里。

我打算尝试将 CRUD 放入静态方法中,即 Customer::save($array) [将根据数组中是否存在 prikey 执行插入和更新]、Customer::delete($id)、Customer: :getObj($id = false) [如果为 false,则获取所有数据]。但对于 32 个模型对象(并且还在不断增长)来说,这将变得痛苦。

此外,有时模型需要交互(如上面用户数据和客户数据之间的交互),这无法在不破坏封装的情况下以静态方法完成。

我设想为此添加另一层(公开 Web 服务),因此知道在某个时候将会有 3 个“控制器”,我需要将此 CRUD 封装在某处(显然),但是静态方法是可行的方法吗?另一条路?

非常感谢您的意见。

This has bothered me for quite a while, but now it is necessity that I find the answer.

We are working on quite a large project using CodeIgniter plus Doctrine.

Our application has a front end and also an admin area for the company to check/change/delete data.

When we designed the front end, we simply consumed most of the Doctrine code right in the controller:

//In semi-pseudocode
function register()
{
  $data = get_post_data();

  if (count($data) && isValid($data))
  {
    $U = new User();
    $U->fromArray($data);
    $U->save();

    $C = new Customer();
    $C->fromArray($data);
    $C->user_id = $U->id;
    $C->save();

    redirect_to_next_step();
  }
}

Obviously when we went to do the admin views code duplication began and considering we were in a "get it DONE" mode so it now stinks with code bloat.

I have moved a lot of functionality (business logic) into the model using model methods, but the basic CRUD does not fit there.

I was going to attempt to place the CRUD into static methods, i.e. Customer::save($array) [would perform both insert and update depending on if prikey is present in array], Customer::delete($id), Customer::getObj($id = false) [if false, get all data]. This is going to become painful though for 32 model objects (and growing).

Also, at times models need to interact (as the interaction above between user data and customer data), which can't be done in a static method without breaking encapsulation.

I envision adding another layer to this (exposing web services), so knowing there are going to be 3 "controllers" at some point I need to encapsulate this CRUD somewhere (obviously), but are static methods the way to go, or is there another road?

Your input is much appreciated.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

悸初 2024-09-11 00:02:17

为什么不使用门面?

class RegistrationManager {
 public function register( $postData, $callBack ){
      $data = get_post_data();
      if (count($data) && isValid($data)){
        $U = new User();
        $U->fromArray($data);
        $U->save();
        $C = new Customer();
        $C->fromArray($data);
        $C->user_id = $U->id;
        $C->save();
        $callBack(); //I like this but you need PHP5.3
      }
     }
 }

在您的应用程序控制器中:

$r = new RegistrationManager;
$r->register( get_post_data(), function(){ redirect_to_next_step(); } );

外观也是模型(在我看来),您可以使用它们来隐藏接线或复杂性并减少代码重复。

Why not use a facade?

class RegistrationManager {
 public function register( $postData, $callBack ){
      $data = get_post_data();
      if (count($data) && isValid($data)){
        $U = new User();
        $U->fromArray($data);
        $U->save();
        $C = new Customer();
        $C->fromArray($data);
        $C->user_id = $U->id;
        $C->save();
        $callBack(); //I like this but you need PHP5.3
      }
     }
 }

In your app controllers:

$r = new RegistrationManager;
$r->register( get_post_data(), function(){ redirect_to_next_step(); } );

Facades are Models too (in my opinion), you may use them to hide wirings or complexities and reduce code-duplication.

君勿笑 2024-09-11 00:02:17

我认为您需要将该逻辑放入表类

class UserTable extends Doctrine_Table
{
  public function register()
  {
    // There you do data model (not concrete object) related stuff
  }
}

http://www.doctrine-project.org/projects/orm/1.2/docs/cookbook/code-igniter-and-doctrine/en

I think you need to put that logic to tables class'es

class UserTable extends Doctrine_Table
{
  public function register()
  {
    // There you do data model (not concrete object) related stuff
  }
}

http://www.doctrine-project.org/projects/orm/1.2/docs/cookbook/code-igniter-and-doctrine/en

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文