Re: Re: frameworks

On Sat, Jan 31, 2009 at 2:16 PM, Nathan Rixham <nrixham@gmail.com> wrote: > 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> > /white flag ? -- http://www.voom.me | EFnet: #voom