Eric Butera wrote:
On Sat, Jan 31, 2009 at 12:06 PM, Shawn McKenzie <nospam@xxxxxxxxxxxxx> wrote:
Eric Butera wrote:
On Fri, Jan 30, 2009 at 7:14 PM, Kevin Waterson <kevin@xxxxxxxxx> 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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
