I don't want to reinvent the wheel, so ask how others do this ...
I have 2 upcoming projects, one in Delphi and one in PHP (plus maybe one in Java), so info specific to those would be welcome, but a generic answer is also acceptable.
So, I have a bunch of PCs and a database server (ODBC) and want to develop an MVC app.
I guess that the Model is on the d/b server and that the view is on each individual PC. Where is the controller? One on the d/b server, or one copy on each PC?
When writing data I imagine it is enough to lock the relevant d/b table(?). But how to update all of those views and tell them that there is new data or that the data which they are working on has been modified on deleted by another user?
Any code is welcome as are URLs or book recommendations ... thanks
Suggest you start with this
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
Its a regular intranet app right? why do you want to split everything separately. Models, views and controllers are just the respective files where you do the relevant stuff, they dont reside physically on a separate locations. I think you have got the Concept of mvc completely wrong. MVC means splitting and layering the code based on their functions not keeping them physically separate.
To be more clear in a laymans language your models views and controllers are just directories in your application. Your view files goes in to your view directory(not necessarily this is changeable though) your models that is your DB related operation files goes into models and the classes that control and drive your app goes into your controller directory.
Running it on intranet is quiet simple. ALl you have to do is host your files on a system that has a static IP or Name within your network then from other systems go to your browser and point your browser at
http://myserver/myapp or http://192.168.100.100/myapp
I dont know anything about delphi, but what ever i said above stands for PHP and many other languages.
So taking all the above points in you are not going to update the views separately on each system all files are in your central server and any changes made in them automatically reflects when requested from the clients.
From your question i assume you are completely new to web development or atleast mvc so first have a look at some simple mvc like codeigniter in PHP. CI has a very good DOC so you can come up to speed.
Hope i have answered all questions.
As far as I understood MVC, there is no rule about the location of the controller itself.
Please take in consideration that MVC is an architectural pattern, not an hardware nor even logical design. If, like in any n-Tier architecture, it could make sense to have the DB in a dedicated computer (for performance and maintainability/backup reasons), controllers and views can be... everywhere...
MVC is a pattern, that is, more a way of modeling/interfacing objects and classes than a way of distributing your application into modules. In fact, you can (and IMHO should) share MVC code among client and servers, whereas the objects are still implementing Model/View/Controllers in a separated way.
A "classic" MVC implementation (e.g. used by RoR or by DoR or Relax in the Delphi world - both in draft status) uses directories or files to split views and controllers. But this is just one implementation design of this pattern.
You can have a pure object MVC orientation, as we implemented for instance in our ORM framework. You can in fact have objects everywhere, to handle your model, to access the DB, to handle your business services.
In our mORMot Open Source framework, for Delphi 6-XE, you can follow this development pattern:
Data Tier is either SQLite3 and/or an internal very fast in-memory database, and/or any other external database (via OleDB or OCI), most SQL queries are created on the fly by the ORM kernel;
Logic Tier is performed by pure ORM aspect: you write Delphi classes which are mapped by the Data Tier into the database, and you can write your business logic in both Client or Server side, just by adding some events or methods to the classes; a Service-Oriented-Architecture (DataSnap-like) is also available, and can be used without any object;
Presentation Tier is either a Delphi Client, either an AJAX application, or any other back-end able to communicate using RESTful JSON over HTTP/1.1 - in this case, PHP or JAVA clients are perfect candidates.
I suggest you take the time to download and take a look at the mORMot documentation. It's far from perfect, but it tries to be complete. In the SAD document, you'll find some pages about the architecture we implemented, in particular MVC, n-Tier, SOA and ORM. Don't be afraid of the 1000 pages of PDF - you don't have to read it all: I just added some general diagrams which may help you modeling your solution.
In all cases, taking a breath before implementing a solution for your project is a very good decision. The time you'll spend now by looking at existing architectures will certainly save you pain in the future. Good start!
Related
I'm interested in hearing about advantages and disadvantages of developing a web application using the OOP paradigm instead of Procedural.
I am NOT interested in
OOP vs Procedural
Contexts other than a typical web application, meaning a distributed application where a client makes an HTTP request to a server
My question is motivated by the fact that I've been developing a web application running on my company's Intranet, and would like this application to be "easily" maintainable by the person who will replace me, eventually, so that the application stay and is not replaced by some over abstracted over engineered paid solution a very few people will enjoy working with.
I posted some bits of my application source for review at codereview from wich I didn't get a lot of feedback. I then posted a link to my post on codereview over at reddit/r/PHP that didn't go really well.
For now, I am under the impression that the vast majority of the "web development" community have decided that OO is the way to go. I'm having a difficult time to understand why BUT I have a feeling that the next dev my company will hire will also be a strong believer in developing OO for a web application as it seems to be the norm nowadays.
I would like to agree with them and join the bandwagon, can someone try and explain to me the advantages and disadvantages of OOP in the typical context of a web application.
While doing some research I came accross this really interesting comment and this one too, wich makes it even harder for me to make the switch.
A small quote from one of the comments:
OOP is for people who can’t properly engineer software or for competent programmers who are involved in very large or complex non-web project. If I were to write an event-driven game to run on a PC, I would not choose procedural programming.
The selling point of a lot of web application frameworks these days is it is an MVC framework. You have the Controller that interfaces with the View and the Model. The model is your business and data layer which contains business objects/entities/data objects - well basically objects that communicate with each other using messages. The objects themselves are restricted to what it is unique to it and only what it can do.
These boundaries/restrictions somewhat make it easier for other people to understand your code and how to modify it. It also helps in unit testing each one of these layers separately.
I suppose if you wanted Rapidly developed application with the controller querying the database and sending information to the view, you could do that too. But the only way to test would be to run the application, check if something breaks, fix, restart it, again test.. You would not be saving a lot of time.
EDIT
You are using a single controller which has business logic in it. But your model looks very much like what an OO model should be. So the question I'd ask is, what happens if I break this controller to be domain specific? I would then have to create a UserController and a DepartmentController and UserController renders all views related to CRUDing Users. Is that worth the trouble? Absolutely. Someone else could jump in and work on AdminController or ReportingController, whatever your application needs without having to worry about changes you are making to this controller.
And if one of you colleagues wants to see some changes done to the Department section, you don't need to worry about the rest.
First of all I'm not a Php person at all but your self praising question seemed interesting so I researched a bit. My answer is general and is not related to a particular implementation of object oriented technology or web technology.
An object encapsulates the data along with the relevant functionality all in a single piece. it is not to say that you encapsulate your whole application inside a single giant object. A lot is related to how you analyze the problem, identity objects and use them.
A web application as a request-response thingy maybe true in early 90s but now the web apps are mature. It is not necessary to follow a typical request-response scenario. Have you seen a stock tracking app? it does not wait for a request to send a response. it sends whenever the data is available. I worked on the online candidate testing web app which asks questions in fixed amount of time. Once the time is up it ends the test whether the user "requests" to end it or not and results are displayed. Even if it user machine is turned off or there is a network issue, it remembers and never asked the same questions again nor extra time was ever given.
Yes there are bad programmers or "IT-guys" who are totally unaware of OO-analysis. They program the object oreinted stuf in a very procedural way. The result of their work is a request-response styled web app with 3 global variables and a 'z' namespace but that does not mean that the blame should go to the OO paradigm itself. It goes to the people who didn't understand it so much for apply it at the right place!
I am making my own MVC framework (please do not downvote me because everyone wants to make a framework.) and so.. I want to make a bootstrapping class like I have seen in many frameworks. I am making this because I have decided to move to the next level by started learning a framework from the inside. But I am facing few problems getting through them. But I will separate them in different questions. Now to clarify my question:
What features should a Bootstrapping class have? And Can you give me articles that could help me?
There should not be a "bootstrap class". It is a straightforward process, which can be contain in a simple script, which would serve as entry point for your application. PHP is not Java, therefore you are not require to contain everything within a class.
Usually bootstrap stage of application would have following responsibilities:
set up the autoloader
initialize routing mechanism
configure storage abstractions (db, cache, etc.)
handle the user request (using the routing)
dispatch to MVC
The bootstrap stage in you application is where all the wiring between objects should be set up. It would also be the place where you set up such things as loggers, access control and error handling structures.
You could say that front controller is a part or bootstrapping.
P.S.: also, you might find this answer of mine relevant, since it also contains an example of bootstrap file.
List of recommended articles:
GUI Architectures by Martin Fowler
Inversion of Control Containers and the Dependency Injection pattern by Martin Fowler
A Description of the Model-View-Controller User Interface Paradigm in the Smalltalk-80 System
Understanding JavaServer Pages Model 2 architecture
MVP: Model-View-Presenter The Taligent Programming Model for C++ and Java
The last two links cover two of 3 major MVC-inspired patterns (Model2 MVC and MVP), since classical MVC is actually highly impractical (and actually, almost impossible) to be used for web applications.
Bootstrapping is just a piece of code that will by executed for each requests.
You can place a function or an object whenever you like more according to your framework dir structure.
It must not have some particular features
I've been learning Zend and its MVC application structure for my new job, and found that working with it just bothered me for reasons I couldn't quite put my finger on. Then during the course of my studies I came across articles such as MVC: No Silver Bullet and this podcast on the topic of MVC and web applications. The guy in the podcast made a very good case against MVC as a web application architecture and nailed a lot of what was bugging me on the head.
However, the question remains, if MVC isn't really a good fit for web applications, what is?
It all depends on your coding style. Here's the secret: It is impossible to write classical MVC in PHP.
Any framework which claims you can is lying to you. The reality is that frameworks themselves cannot even implement MVC -- your code can. But that's not as good a marketing pitch, I guess.
To implement a classical MVC it would require for you to have persistent Models to begin with. Additionally, Model should inform View about the changes (observer pattern), which too is impossible in your vanilla PHP page (you can do something close to classical MVC, if you use sockets, but that's impractical for real website).
In web development you actually have 4 other MVC-inspired solutions:
Model2 MVC: View is requesting data from the Model and then deciding how to render it and which templates to use. Controller is responsible for changing the state of both View and Model.
MVVM: Controller is swapped out for a ViewModel, which is responsible for the translation between View's expectations and Models's logic. View requests data from controller, which translates the request so that Model can understand it.
Most often you would use this when you have no control over either views or the model layer.
MVP (what php frameworks call "MVC"): Presenter requests information from Model, collects it, modifies it, and passes it to the passive View.
To explore this pattern, I would recommend for you begin with this publication. It will explain it in detail.
HMVC (or PAC): differs from Model2 with ability of a controller to execute sub-controllers. Each with own triad of M, V and C. You gain modularity and maintainability, but pay with some hit in performance.
Anyway. The bottom line is: you haven't really used MVC.
But if you are sick of all the MVC-like structures, you can look into:
event driven architectures
n-Tier architecture
And then there is always the DCI paradigm, but it has some issues when applied to PHP (you cannot cast to a class in PHP .. not without ugly hacks).
From my experience, the benefits you get from an MVC architecture far outweighs its costs and apparent overhead when developing for the web.
For someone starting out with a complex MVC framework, it can be a little daunting to make the extra effort of separating the three layers, and getting a good feel as to what belongs where (some things are obvious, others can be quite border-line and tend to be good topics of discussion). I think this cost pays for itself in the long run, especially if you're expecting your application to grow or to be maintained over a reasonable period of time.
I've had situations where the cost of creating a new API to allow other clients to connect to an existing web application was extremely low, due to good separation of the layers: the business logic wasn't at all connected to the presentation, so it was cake.
In the current MVC framework eco-system I believe your mileage may vary greatly, since the principles are common, but there are alot of differences between, for instance, Zend, Django, RoR and SpringMVC.
If there are truly other good alternatives to this paradigm out there... I'm quite interested in the answers!
Sorry for the slight wall of text!
I think it would depend on what you're trying to do, personally. Magenta uses MVC pretty successfully, and it makes it fairly easy to add new functionality or modify existing.
Of course if you're trying to make something fairly simple, going with an MVC architecture could be overkill.
It's all preference. I have worked with old structures like XTemplates and Smarty and have now moved on to Codeigniter and Kohona. I like them very much and they work very well for everything I do on the web. For phone applications I can set up controllers for the functions that are needed to do it's data pulls as well. Working both in the Linux world and Windows World, for building ASP.NET Web Sites I don't see other way of building websites beside using MVC. Web Applications Projects in Visual Studio are still used but I prefer not to anymore. MVC Projects via Visual Studio is so easy to use and set up. You can right click on your controller methods and create views automatically. In every structure there is a good and bad but it's up to the developer to use whatever meets their needs.
I have asked a similar question before and got an convincing answer as well?
What is difference of developing a website in MVC and 3-Tier or N-tier architecture?
Due to the conclusion of this question I started developing projects in N-tier Architecture.
Just about an hour ago, I asked another question, about what is the best design pattern to create interface? There the most voted answer is suggesting me to use MVC architecture.
What is the best design pattern to design the interface of an WebPage?
Now I am confused, First post suggested me that both are similar, just a difference that in N-tier, the tier are physically and logically separated and one layer has access to the one above and below it but not all the layers.
I think ASP.net used 3 Tier architecture while developing applications or Web applications. Where as frameworks like Zend, Symphony they use MVC.
I just want to stick to a pattern that is best suitable for WebProject Development? May be this is a very silly confusion? But if someone could clear this confusion, that would be very greatful?
They aren't mutually exclusive. The Model-View-Controller pattern is really a user interface design pattern, and it concerns logical rather than physical tiers.
I most often hear "n-tier architecture" used to describe the actual physical separation of an application's layers. For example, a system in which the user interface runs in one process, exchanges data with an application layer (perhaps via messaging or web services) that executes in another process (perhaps on another server), which in turn accesses a data layer that runs in yet another process (typically a database server).
This description can be particularly confusing because 'application logic' can mean multiple things: in an n-tier system it usually means business logic - as opposed to user interface logic (like which widgets are enabled when the user selects a particular checkbox).
For example, in an n-tier system, your presentation layer might call a web service method that accepts an item ID. The web service runs on a different server, where it performs complicated calculations and returns a price.
In a simpler architecture, your application might calculate the item's price in the same process as the user interface - though the pricing logic may be separated into its own logical layer (perhaps within library or executable).
I can't think of any current MVC frameworks that care whether their layers run in separate physical processes or not.
I just want to stick to a pattern that
is best suitable for WebProject
Development? May be this is a very
silly confusion? But if someone could
clear this confusion, that would be
very greatful?
I think your confusion lies in two areas:
1) The assumption that there's one solution for every problem.
The requirement of your project will dictate which solution is best.
2) The definition of MVC when applied to the web is different than when it originally applied to desktop applications.
Some folks say that if the view doesn't talk to the model, then it can't be MVC. Well, most of the web MVC implementations don't have the view talk to the model, yet it's still called MVC.
Since you are a self-described amateur, you should embrace this one axiom early on: the programming world is confusing to everyone all the time.
You may want to review the Microsoft Application Architecture Guide. It has a good overview of the available Microsoft technologies from an Architecture standpoint. Chapters that might be of interest to you:
Chp 21 Designing Web Applications
Appendix B: Presentation Technology Matrix
Appendix C: Data Access Technology Matrix
As for what is best? You have to answer that yourself. Make some sample projects using MVC, WebForms, etc.
Web-based MVC is much different than the traditional desktop MVC. The Model simply has no way to update the View, because the web is (for the most part) stateless.
Even if you used AJAX to poll the server every couple seconds to check for Model updates, that still wouldn't be "true" MVC because it's not the Model notifying the View, it's the controller constantly "querying" the Models.
The lesson learned is that it really doesn't matter what you label your architecture. There are just so many variants of MVC/3 tier that usually people just lump them under the "MVC" blanket. And all of these are suitable for web development. I just can't think of any practical way to have the Model actually notify the View through server-side programming (at least not in PHP). If you need this kind of behavior, you should be writing a desktop application. Just write what is natural for you and don't get caught up in terminology debates. Look at what some of the well known frameworks like CodeIgniter, Kohana, Symfony, CakePHP, and Zend do and pick and choose which features or design patterns you like.
Why not use both?
At the moment I'm busy developing a project using the MVP pattern and in an N-tier architecture.
I'm using the MVP pattern in the user interface project, ie. the website. All the data which needs to be shown and used in the website is passed from a webservice. This webservice is connected to a business layer (BLL), which is connected to the data access layer (DAL). The DAL is connected to the database using the Entity Framework.
So in this project I'm using them both. Using MVP instead of MVC though.
This way the interface project (website) doesn't has to do hard stuff, only pass through some data which is received from the webservice. Took me a while to set up, but it works quite wonderfull.
Also, there is no real answer to which pattern or architecture is the best. It all depends on what you want and need. If you want to be scalable, an n-tier architecture is a good solution. If you want to be able to test your UI quite easily, an MVC pattern is good also. There's a ton of other patterns and architectures which would suffice as well, as long as you know how to use them.
There is no which is better. MVC and n-tier are not either or things. One is object/API design, one is system architecture. The question to distinguish between the two has been asked and answered here:
MVC Vs n-tier architecture
I'm going to write a framework for my web projects in PHP.
Please don't tell me about considering to use some existing framework (Cake, CodeIgniter, Symfony, etc.) - I have already had a look at them and decided to write one for myself.
The framework itself will mainly consist of a module system, a database handler and a template parser. (Many other things too, of course)
With module system I mean that every module has exactly one PHP file and one or more templates associated with it.
An example module would be modules/login.php that uses templates/login.tpl for its design.
These days everyone(?) is talking about the MVC (Model View Controller) concept and most of the existing frameworks use it, too.
So my questions are the following:
Is MVC really effective for a personal framework?
Would it be a bad idea to use a module system?
Did you ever write a framework for yourself? What are your experiences?
Is MVC really effective for a personal framework?
Yes, it can be. Although, it might be a little overkill (which, is not necessarily a bad thing if you are trying to learn)
Would it be a bad idea to use a module system?
This is never a bad idea.
Did you ever write a framework for yourself? What are your experiences?
I wrote a common security framework for my group's PHP applications when I was an intern. I learned alot, but the project as a whole might have benefited more from a pre-built solution.
Of course, I wouldn't have learned as much if I just installed a pre-built solution. So you always have to take that into account, especially for personal projects. Sometimes re-inventing the wheel is the only way you will learn something well.
Is MVC really effective for a personal framework?
What MVC means anymore, due to its vague interpretation, is business logic, presentation, and input handling. So, unless you aim to design an application that does not involve any three of those, MVC is, in its vague sense, very suitable.
Often it can be more formal than you desire, however, as it demands physical separation of ideas into different code files. Quick and dirty tasks or rapid prototyping might be more quickly setup if the formalities are avoided.
In the long term, what MVC asks for is beneficial to the sustainability of the application in ways of maintenance and modification or addition. You will not want to miss this. Not all frameworks encourage the right practices, though. I am not surprised that you find the various implementations you've tried insufficient. My personal favourite is Agavi. To me and others, in a world of PHP frameworks that do not feel right, Agavi emerges to do the right things. Agavi is worth the shot.
Would it be a bad idea to use a module system?
MVC asks you to separate components of business logic, presentation, and input handling, but it does not suggest how to layout the files. I presume this is the challenge you are addressing with a module system. To answer your question: modules serve identically to sub-directories. If the items are few, its probably more hassle to bother with subdirectories even if the files could logically be separated into them. When the number of items grow large, its now cumbersome to locate them all and sub-directories become a better option.
Frameworks will tack on functionality that allows you to deal with modules as their own configurable entity. The same functionality could just as well exist without modules, perhaps in a more cumbersome manor. Nonetheless, do not consider modules primarily as a system. Systems are so wonderfully vague that you can adapt them to whatever setup you find suitable.
Did you ever write a framework for yourself? What are your experiences?
Yes I have wrote several frameworks with various approaches to solving the issues of web applications. Every such framework I wrote became nothing but a vital learning curve. In each framework I made I discovered more and more the issues with building software. After failing to create anything interesting, I still gained because when asked to make a program I could fully do so with justice.
I recommend you continue if this is the sort of learning experience you want. Otherwise, give Agavi a shot. If that too fails, ensure that you have a clear and detailed specification of what your framework will do. The easiest way to barge into making software, work really hard, and accomplish nothing is to not decide before-hand what exactly your software will do. Every time I ran into making code the only thing in my mind was I will do it right. What happened was a different story: oh, well I need to make a routing system as that seems logical; hmm, okay, now I need a good templating system; alright, now time for the database abstraction; but gee, what a lot of thinking; I should look to the same system from software XXY for inspiration. Therein is the common cry that pleads to use existing software first.
The reason I thought I could do it right was not because all the nuts and bolts of the framework felt wrong. In fact, I knew nothing about how right or wrong they were because I never worked with them. What I did work with was the enamel, and it felt wonky. The quickest way to derive your own framework is really to steal the nuts and bolts from another and design your own enamel. That is what you see when building an application and frankly is the only part that matters. Everything else is a waste of your time in boilerplate. For learning how to build software, however, its not a waste of time.
If you have any other questions, please ask. I am happy to answer with my own experience.
I am also actually writing a php framework with a friend of mine. I absolutely can understand what you do.
I thing what you are doing is near mvc. You have the templates as views. And the modules as controller. So I think that is ok. The only thing you need is the model. That would be some kind of active records.
In my framework there are simular concepts, except we are writing our own active records engine at the moment. I think what you do isn't bad. But it's hard to say without seeing code.
I see only one problem you have to solve. A framework should be perfectly integrated. It is always a complicated to make your module look nice integrated without always have to think of module while you are coding application.
Is MVC really effective for a personal framework?
Would it be a bad idea to use a module system?
Yes it is. But MVC is such a loosy-goosy design pattern that you can draw the line between model, view, and controller anywhere you want. To me, the most important parts are the model and the view. I simply have pages, php modules, that generate html by filling in a template from a database. The pages are the view and the database is the model. Any common application-specific code can be factored out into "controllers". An example might be a common, sophisticated query that multiple pages must use to render data.
Other than that I have utilities for safe database access, simple templating, and other stuff.
Did you ever write a framework for yourself? What are your experiences?
Yes. I'm very glad I did. I can keep it simple. I know intimately how it works. I'm not dependent on anyone but myself. I can keep it simple yet useful.
Some pointers (0x912abe25...):
Every abstraction comes with a cost.
Don't get to fancy. You might regret not keeping it simple. Add just the right amount of abstraction. You may find you over-abstracted and something that should be simple became excessively complex. I know I've made this mistake. Remember You-aint-gonna-need-it.
Scope your variables well
Don't load your pages by doing
include_once('...page file ...');
where it's expected that page file will have a bunch of inline php to execute looking up different global variables. You lose all sense of scope. This can get nasty if you load your page file from inside a function:
function processCredentials()
{
if (credentialsFail)
{
include_once('loginpage.php');
}
}
Additionally, when it comes to scoping, treat anything plugged into templates as variables with scope. Be careful if you fill in templates from something outside the page file associated with that template (like a master index.php or something). When you do this it's not clear exactly what's filled in for you and what you are required to plug into the template.
Don't over-model your database with OO.
For simple access to the database, create useful abstractions. This could be something as simple as fetching a row into an object by a primary index.
For more complex queries, don't shy away from SQL. Use simple abstractions to guarantee sanitization and validation of your inputs. Don't get too crazy with abstracting away the database. KISS.
I would say that MVC makes more sense to me, since it feels better, but the only practical difference is that your login.php would contain both the model (data structure definitions) and the controller (code for page actions). You could add one file to the module, e.g. class.login.php and use __autoload() for that, which would essentially implement an MVC structure.
I have refactored a big PHP project to make it more MVC compliant.
I found especially usefull to create a DAO layer to centralize all database accesses. I created a daoFactory function, which creates the DAO and injects the database handle into it (also the logger, I used log4php, got injected).
For the DAO, i used a lot the functionalities of the database (mysql), like stored procedure and triggers. I completly agree with Doug T. about avoid over-abstraction, especially for database access : if you use the DB properly (prepared statements, etc.) you don't need any ORM and your code will be much faster. But of course you need to learn mysql (or postgress) and you become dependant on it (especially if you use a lot of stored procedure, like I tend to do).
I am currently refactoring a step further, using the Slim php framework and moving toward a restfull api : in this case there is no view anymore because everything is outputted as json. But I still use smarty because its caching works well and I know it.
Writing a framework could be a rewarding experience. The important thing to consider is that you do not write a framework for its own sake. The reason one writes a framework is to make development easy.
Since it is a personal framework you should think in terms of how it could help you develop with less hassle.
I do not think a template system is a good idea. Think of it - what is the major benefit of using a template system? The answer is that it helps teams with different skill sets jointly develop an application. In other words, some members of the team can work on the user interface and they do not need to be PHP coders. Now, a personal framework will most likely be used by a single person and the benefit of template system becomes irrelevant.
All in all, you should look at your own coding habits and methods and discover tasks that take most of your time on a typical project. Then you should ask yourself how you can automate those tasks to require less time and effort. By implementing those automation mechanisms you will have to stick to some sort of conventions (similar to an API). The sum of the helper mechanisms and the conventions will be your personal framework.
Good luck.
MVC doesn't work
you don't want to be constrained in the structure of your "modules"; also, keep templates close to the code (the templates directory is a bad idea)
no
re 1.: see Allen Holub's Holub on Patterns. briefly: MVC basically requires you to give up object oriented principles.
Tell Don't Ask is a catchy name for a mental trick that helps you keep the data and code that acts on it together. Views cause the Model to degrade into a heap of getters and setters, with few if any meaningful operations defined on them. Code that naturally belongs in the Model is then in practice spread among Controllers and Views(!), producing the unhealthy Distant Action and tight coupling.
Model objects should display themselves, possibly using some form of Dependency Injection:
interface Display
{
function display($t, array $args);
}
class SomePartOfModel
...
{
function output(Display $d)
{
$d->display('specific.tpl', array(
'foo' => $this->whatever,
...
));
}
}
OTOH, in practice I find most web applications call for a different architectural pattern, where the Model is replaced with Services. An active database, normalized schema and application specific views go a long way: you keep the data and code that acts on it together, and the declarative nature makes it much shorter than what you could do in PHP.
Ok, so SQL is a terribly verbose language. What prevents you from generating it from some concise DSL? Mind you, I don't necessarily suggest using an ORM. In fact, quite the opposite. Without Model, there's little use for an ORM anyway. You might want to use something to build queries, though those should be very simple, perhaps to the point of obviating such a tool...
First, keep the interface your database exposes to the application as comfortable for the application as possible. For example, hide complex queries behind views. Expose update-specific interfaces where required.
Most web applications are not only the owners of their respective underlying databases, they're their only consumers. Despite this fact, most web applications access their data through awkward interfaces: either a normalized schema, bare-bones, or a denormalized schema that turned out to make one operation easier at the price of severe discomfort elsewhere (various csv-style columns etc). That's a bit sad, and needlessly so.
re 2.: it's certainly good to have a unified structure. what you don't want to do is to lock yourself into a situation where a module cannot use more than one file.
templates should be kept close to code that uses them for the same reason that code that works together should be kept together. templates are a form of code, the V in MVC. you'll want fine-grained templates to allow (re)use. there's no reason the presentation layer shouldn't be as DRY as other parts of code.