On Sat, Jan 31, 2009 at 1:12 PM, Nathan Rixham <nrixham@xxxxxxxxx> wrote: > 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 > This is php we're talking about, not java! :D -- http://www.voom.me | EFnet: #voom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
