Hi Ralf!
> Sorry, I really don't get it. If I build my book shop with the ZF
than > I build it to use the ZF and the infrastructure of the framework.
No. I wouldn't do that, ever.
You don't start designing software by asking "ok, what kind of
framework we want to use?", do you?
But you start by examining what the problems and requirements are
that you have to put into written code and being executed by using one
(or more) application(s). You think about use cases, layering,
interfaces and how you want to work with your software from any
application that may come.
Well, it's the old story of decoupling and maintainability.
And "layers" and domain model centric software design.
> So are you saying that I should build my controller classes indepently
> of the particular framework implementation to be able to use the same
> controller classes in both my ZF and CakePHP implementations?
Yes!
Well not exactly. It doesn't matter how you build your controllers.
But it really does matter how you build your software.
Your software is the book shop, right?
Does it only work and you sell books with using ZF?
I don't think so.
Software has to execute some business needs, right?
Regardless of the application using it. Only the application may have
limits (like an handheld not able to show the nice 3d pictures of some
products or processing forms). But the software itself does always know
everything it should know.
I guess you know all the following quite well but perhaps some others do
not, so I will explain it a little more detailled.
I assume a typical three-tier layering for my further comments here.
Normally this are (from top to down):
Presentation (View)
Application (Controller)
Domain (Model?)
Zend doesn't use the Model and that's for good. Sometimes there is a
fourth (or fifth...) layer at its best, the Infrastructure (or
Persistance) layer.
The Domain layer should be THE place for the real domain of the
software, avoiding as much coupling to infrastructure/persistance as
possible.
And every application (layer) should be as thin as possible.
Ok, let's build a software for selling books :-)
The calls from an web (or http) application may look like this:
$customer = $myApp->registerCustomer('John Doe', 'Password');
...
$order = $myApp->createOrder($customer);
$order->addProduct($product, $count);
$order->finalChecking()->save();
Behind the scene is my actual software, it fulfills all the steps
that were "started" by the application and may look like this:
...
$order = new Order($customer);
$order->addLine(new Orderline(new Product('ISBN-123-456', 2));
->addLine(new Orderline(new Product('ISBN-578-333', 1));
It's nothing else than an API. Like calling Zend_Date or any other class
and knowing what is possible and what not (leaving out the extension of
them here).
So, having a MVC framework like ZF, CakePHP or
<place-your-favorite-mvc-fw-here> doesn't matter, the calls would be
always the same. Having no MVC framework doesn't matter too. You guess
it: the way I work with my software stays the same.
The interface to my software reveals its intention.
I clearly say "create a new order -> add a product to it -> save (order) it"
You can "read" the code, there are no framework or technical gimmicks
nor exotic naming conventions that darkens the intention.
(This is also a problem with PHP not having namespaces, therefore the
naming conventions like in ZF exist. A class "Orderline" has a clear
concept, wearing its flag in the name but does
"MyApp_Domain_Component_Order_Line" has so?)
You may say "Hey, but that's all the stuff my models can do, isn't it?".
Well, is it?
Do your models use such business concepts or do they only reflect
your database? Perhaps both, that would be a little bit better.
If the latter is true you even though have the same type of dependance
to another technolgy: the database (or any persistance type).
How do you change that easily, how do you maintain it and how do
you test it?
Always keep in mind the following when you don't know where to put in
some functionality or how to design a part of your software:
You have a web application that does some stuff, now your customer wants
another kind of application (Desktop, iPhone, even another Web application).
Or you simply create an imaginary one, that helps too.
Can you use the same code or do you have to duplicate or rewrite all the
complex code you created and used in your application into the new one?
Everything that is used by ALL applications or has to be duplicated
between them is a sign that it really belongs to the domain layer,
the "real" piece of software, used by every application.
So you can't and shouldn't put logic that every application could (or
should) use in your controllers. It belongs in the domain model.
Your controllers are then what they should be in a classic MVC pattern:
thin application entry points delegating to more complex layers like the
domain and applications-specific handling of requirements (like
authentication, logging, sessions and so on). Nothing more and nothing
less.
Keep the software doing what it should.
Make it right.
Then think about how to build the application.
Using it.
Cheers,
Nino
