Comments on: Domain Model Programming With the Zend Framework

By: Domain Model ORM Adapters | Realm of Zod

Domain Model ORM Adapters | Realm of Zod — Sun, 24 Jan 2010 20:12:20 +0000

[...] will be building upon the foundation I have laid in past articles so you may want to catch up: Domain Model Programming with the Zend Framework Doctrine, Complex SQL Queries, and [...]

By: Doctrine és Zend Framework integráció « vbali blogja

Doctrine és Zend Framework integráció « vbali blogja — Sun, 24 Jan 2010 13:17:55 +0000

[...] sajnos sosem jártam igazi sikerrel. Kipróbáltam mások elképzeléseit is (Model Infrastructure, Domain Model Programming With the Zend Framework) de hosszabb távon, az igények növekedésével ezek a megvalósítások mindig zsákutcának [...]

By: rvdavid

rvdavid — Sat, 10 Oct 2009 02:42:47 +0000

Hi, Just wanted to stop by to tell you that I decided to try Doctrine out as per your recommendation on my blog post: http://blog.rvdavid.net/zend-framework-model/

Puts the final piece of the puzzle for me. I was planning on implementing my own DataMapper / Model layer, Doctrine actually does all this for me.

Thank you for your recommendation.
Keep in touch!

By: Doctrine, Complex SQL Queries, and Paginators | Realm of Zod

Doctrine, Complex SQL Queries, and Paginators | Realm of Zod — Thu, 08 Oct 2009 00:49:50 +0000

[...] Some time ago I wrote an article on how to implement domain model programming with the Zend Framework while using Doctrine for your Object Relational Mapper (ORM), you read it here: [...]

By: Zend Framework Model – Research into Possible Domain Model Solutions : rvdavid: A Web Developer’s Blog

Wed, 30 Sep 2009 15:34:50 +0000

[...] and one of the entries that piqued my interest was a post by brandon from realm of zod titled: Domain Model Programming With the Zend Framework which talks about using Doctrine ORM instead of Zend DB Table’s Table Data Gateway [...]

By: brandon

brandon — Tue, 14 Jul 2009 16:50:15 +0000

That’s correct. The model has no concept of the persistence layer at all. It’s best to treat all CRUD operations as atomic, meaning queue up the data that needs to be saved or altered in the model class and pass it all in to the gateway when save is called and let the gateway sort everything out. The exception is when you need to pull in related records (One to One, One to Many, etc), you can lazy load a collection of related records by requesting them from the gateway which knows how to retrieve them using the model’s id.

By: Jim

Jim — Tue, 14 Jul 2009 03:28:28 +0000

nice post Brandon, I was reading the same article by Matthew but I could not figure out if the User model had a domain logic method like…

$userGateway = new UserGateway();
$user = $userGateway->find(4);
$user->updatePayrollDeduction(5);
$userGateway->save($user);

if the updatePayrollDeduction method needed access to the db, would it just call it’s own gateway when it needed DB info? I’d imagine no DB references would be in the model itself?

thanks

By: brandon

brandon — Mon, 27 Apr 2009 13:31:13 +0000

The FP_Model_Gateway class is nothing more than an abstract class so it actually implements nothing. All it provides is a stub for fetch() in order to adhere to the FP_Model_Gateway_Interface. It’s purpose is to provide an interface for FP_Model_Paginator_Adapter

By: Jacob

Jacob — Sun, 26 Apr 2009 17:35:53 +0000

Thx for this great article!

But I’ve one question: your class Doctrine_Users extends the class FP_Model_Gateway. But you didn’t post that class here, or did I only overlook it?

By: Modular Zend Framework Skeleton 2009 | Realm of Zod

Modular Zend Framework Skeleton 2009 | Realm of Zod — Wed, 08 Apr 2009 20:30:15 +0000

[...] The only major deviation I have made from the past versions of the skeleton is the migration from Zend_Db to Doctrine and the use of domain model programming which only affects the module model folders. For more on this, see my recent article about it. [...]