Re: Re: frameworks

Eric Butera wrote:

On Sat, Jan 31, 2009 at 1:12 PM, Nathan Rixham <nrixham@gmail.com> wrote:

Eric Butera wrote:

On Sat, Jan 31, 2009 at 12:06 PM, Shawn McKenzie <nospam@mckenzies.net> wrote:

Eric Butera wrote:

On Fri, Jan 30, 2009 at 7:14 PM, Kevin Waterson <kevin@phpro.org> wrote:

On Fri, 2009-01-30 at 18:03 -0600, Shawn McKenzie wrote:

From what I could tell, this was the best RAD, however if you prefer to lay everything out your own way and do things your own way then probably CI or Zend.

I use Zend every day in my current employ. It is like pulling teeth and its feature set is not as rich as they would have you believe. Zend DB is pathetic Zend Form (although not from Zend itself) is abstraction for abstractions sake and is mind numbingly complex. The lack of a model loader is laughable. The list goes but you get the point, this is supposed to be from "the makers of PHP" and is supposed to be a mature framework and ready for enterprise level applications. What a joke. but, just my $0.02 Kevin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php

And what exactly do you expect for the model layer? That's the part you are supposed to write on your own.

Supposed to? Who says? The DB yes, but if you design the DB correctly and want your models tightly coupled with the DB, then it is an useless step to create the model yourself. Zend has a Zend_Tool script in the incubator that does project and some code gen. Reading the plans they plan to include model generation as well. It will probably be a while in coming though. To me, right now Zend is just a more professional and consistent PEAR, but with fewer features. -- Thanks! -Shawn http://www.spidean.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php

Model != database. I made this mistake for years, but no more! :) Models can persist data, but a model is supposed to be the business logic of your app. It's a set of rules. So how could any tool generate your app for you is/was my point. Take an ecommerce example. You might have a product in the database, but calculating it's price based on categories, sale prices, etc isn't something that a database is going to do. That is your app's logic & is part of your model. The model can ask the DB for all that static info about pricing, but it makes the determination as to what the price is. What about when you want to add a product to the cart? Where would you ask the code if that product is already in the cart? Just all those types of things...

actually (imho?).. Model != Database Model != Business Logic A model class describes the structure of data, and has methods to ensure the instance properties are of the correct format and valid so that they can be persisted. Let's say a simple User class class User { private $id; private $name; public function getId() { return $this->id; } public function setId( $id ) { // logic to ensure $id is the correct format to persist // let say just a valid int $this->id = $id; } public function getName() { return $this->name; } public function setName( $name ) { // logic to ensure $name is the correct format to persist // let's say a string under 64 chars $this->name = $name } } how it's persisted is out with the scope of this mail, and varying techniques exist, however this is normally inside the domain model layer (but not necessarily the model classes themselves) The above keeps you're domain model clean and free from implementation specific idiosyncrasies. This is especially useful when working on n-tier/3-tier architectures, building a framework, or a single codebase to be used across multiple sites. All the implementation specific code comes in at the business layer, which is where all you're business logic also occurs. thus: Business layer asks domain model layer for a "new user", domain model layer returns a new empty instance of the user class. Business layer does it's thing and ends up populating the user instance with data that valid for the specific application (let's say a name string 8-16 alphanumeric chars) Business Layer then passes it back to the domain model layer to persist; the domain model layer either persists the data OR returns back an exception should the instance properties not be valid to persist, or if an error occurred. regards :p

This is php we're talking about, not java! :D

dude you're gonna have to stop using that language as an excuse to negate everything I say <weg>