Re: [fw-mvc] Another Model Design Thread

Wouldn't this be considered an Anemic Domain Model?

I am considering a design like this for a project I am working on. I like
the idea of Product_Bean accessors since it shields the view from any field
name change in the data source. It also lets me create specific accessors
that may aggregate internal fields so I don't have to concatenate values in
my view.

I was about to move forward with a design like this but I came across some
articles online suggesting this was a bad move..

Perhaps I have the concept of the Anemic Domain Model backwards?

Does anyone have any thoughts on this design?

Xavier Vidal Piera wrote:
>
> I've forgot to specify how Zend_Db_Table saves a Bean:
>
> Inside Product_Model
>
> public function save(Product_Bean $product)
> {
> $data = array('name' => $product->name);
>
> if(is_numeric($product->id)) {
> $this->table->update($data, "id = $product->id");
> } else {
> $this->table->insert($data);
> }
>
> ...
> }
>
> With this approach, i can do some testing with fake beans, complex models,
> etc. so data source can be easily replaced or shared (databases, xml-rpc,
> files...).
>
> I understand there's a great temptation to use Zend_Db_Table as a model
> (if
> you want a simple web application like a tiny blog or a event log), but
> it's
> better to design your own model and no rely in databases classes.
>
> On Wed, Dec 10, 2008 at 9:15 AM, Xavier Vidal Piera
> <xavividal@gmail.com>wrote:
>
>> Hi
>>
>> When i started with ZF i was tempted to follow the Zend_Db_Table
>> inheritance to build my model, and i quickly realized that this approach
>> was
>> wrong.
>>
>> I will show my actual way of work: "Beans":
>>
>> Take as example, the "Product" Bean, with only getters and setters
>> methods,
>> with one field for each database field. We can have extra bean fields if
>> we
>> need them (calculated, flags, etc..).
>>
>> We can have a "Product" Table class, but this class only knows to load
>> and
>> save arrays of data.
>>
>> The "Product" Model class is the responsible of fetching the Bean,
>> filling
>> Beans from arrays and doing extra methods (like retrieve the product's
>> manufacturer).
>>
>> So, if i want to get a Product with id 50, this will be the steps.
>>
>> Inside Controller:
>>
>> $mProduct = new Product_Model();
>> $product = $mProduct->fetch(50);
>>
>> Inside Model:
>>
>> public function fetch($id)
>> {
>> $tProduct = new Product_Table();
>> $rProduct = $tProduct->fetchAll("id = $id")->current()->toArray();
>>
>> return self::fillBean($rProduct);
>> }
>>
>> public static function fillBean(array $data)
>> {
>> $product = new Product_Bean();
>> $product->id = $data['id'];
>> $product->name = $data['name'];
>> ....
>> return $product;
>> }
>>
>> Ok, this is so simple you can say this operation could be done with
>> Zend_Db_Table, but when the complexity arises is when the Bean has
>> relations
>> (A Product bean could have a variable that stores a Manufacturer Bean
>> (loaded with lazy loading...)), or the "save" method from model needs to
>> do
>> some different operations (save a product, update the log, check stocks,
>> etc.).
>>
>> Ah, and don't forget database transactions. Where will you put the begin
>> and commit? These must be put at the very beginning and end of the model
>> operation, because it's not Zend_Db_Table responsability.
>>
>> These are my 0.05...
>>
>>
>>
>>
>> On Wed, Dec 10, 2008 at 7:58 AM, webPragmatist
>> <chris@webpragmatist.com>wrote:
>>
>>>
>>> *GULP*
>>>
>>> Hey Matthew,
>>> Can you just elaborate on this?
>>>
>>>
>>> Matthew Weier O'Phinney-3 wrote:
>>> >
>>> > Now, all that aside... you can do all of this using Zend_Db_Table as
>>> > your base model as well. I choose not to, but I totally understand
>>> your
>>> > arguments.
>>>
>>> Do you simply use the objects inside of your model?
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Another-Model-Design-Thread-tp20909700p20930074.html
>>> Sent from the Zend MVC mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>> --
>> Xavier Vidal Piera
>> Director Tècnic de Citrusparadis.com - Grupo Intercom
>> Enginyer Tècnic Informàtic de Gestió
>> Tècnic Especialista Informàtic d'equips
>> xavividal@gmail.com
>> http://web.xaviervidal.net
>> 610.68.41.78
>>
>
>
>
> --
> Xavier Vidal Piera
> Director Tècnic de Citrusparadis.com - Grupo Intercom
> Enginyer Tècnic Informàtic de Gestió
> Tècnic Especialista Informàtic d'equips
> xavividal@gmail.com
> http://web.xaviervidal.net
> 610.68.41.78
>
>

--
View this message in context: http://www.nabble.com/Another-Model-Design-Thread-tp20909700p21058411.html
Sent from the Zend MVC mailing list archive at Nabble.com.