Jump to content

MVC application layers


nankoweap

Recommended Posts

ok. so i've been around here for a short time and have seen a lot of php code. i've almost completed porting one of my java/jsp-based apps to php and feel i have a good understanding of how i will structure the other apps that i'll begin porting soon. they should port more quickly.

 

one thing i've enjoyed in the java world is the strict boundaries between the MVC layers - provided it's designed and implemented that way. the model has always been implemented in a well-structured layer of components that accept data requests from the controllers, interact with the database and return results, if any. the controlling layer is a set of servlets that service each request, makes requests of the model and eventually forward "stuff" to the view. the viewing layer is a set of jsp pages responsible for user presentation.

 

in the php world, my php world at this point :), i've implemented the model in much the same way as before. this pleases me greatly as i prefer clear, well-defined application boundaries. the controlling and viewing layers, however, are physically semi-married in one php page. i don't have a real issue with this as the controlling layer should be thin and focus primarily on input validation, make requests of the model and allow the view to do its job of presentation. so the controlling layer is a short, concise and focused bit of php code at the beginning of each page. the view is the html and small bits of php used to cycle through arrays and such to build the visual components on the screen such list boxes, tables, etc. so even though i've married the VC layers in a single page, each layer is still clear and well-defined. this all pleases me.

 

what i've seen in a lot of the code that folks post show a coupling (by printing and echoing large chunks of html) of the VC layers that would concern me greatly if it was a project i was managing technically. why? because people on projects play roles and this type of coupling tends to make programmers web-designers. only speaking for myself, this is not good because i have zero artistic capability as evidenced by the web apps i've created in the ether:

 

http://jasonjonas.org/spot

http://jasonjonas.com/rides

http://jasonjonas.com/miles (this is the one i'm porting currently)

http://jasonjonas.com/mtfta

 

anyway, look at any of these apps and my lack of visual/artistic ability is evident. i can make it work, but i cannot make it look good. and that's why i'm a server-side guy. i'm good with nuts and bolts.

 

these are all merely apps i've created and make freely available to the motorcycling community as well as anyone else who can make use of them. but with clearly defined VC layers, i could have a web-designer-type person make these pages look mucho better without having to deal with a boat load of java or php code. again, the bulk of the view is html with bits of java/php to help build some of the visual components.

 

so my question in all of this is... if you're responsible for the design/implementation of a large php application with a good number of folks on your team, have you designed it with clear and well-defined application layer boundaries or have you, for whatever reasons, allowed some layers to overlap? if so, which ones and to what extent? what issues did this cause, if any? for the applications i've designed for my customers in the java world, these boundaries are essential in order to clearly define the roles and responsibilities of each person on the project.

 

sorry for the long post. i've always been verbose.

 

jason

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.