An MVC alternative that is loosely coupled?

Question

I work in an online store as a PHP programmer. In most cases, we use good coding methods, but not much structure for the site as a whole.

Now I have entered my phase of boredom with some of our practices and I want to branch out and simplify and generate some useful things not only for me, but also for web-based hybrids developers in the office.

One employee left us an MVC site written in PHP, and I had to maintain it a bit, and I understand how it works, but I have complaints. My main complaint is that it is closely related to each part that depends on the other. I see the advantage of sharing problems, but it will be confusing to anyone but me looking at the code.

So, for example, if I need to add a new page to a site, I need to add a view, and then add a model, and then update the controller. The special way to create a new page is simpler than this and does not require a programmer.

My opinion was that it was a much better method for creating, not supporting, a website.

However, it would be nice if I had some design patterns where I could reuse the code efficiently without depending on several places on the site.

So my question is, is there a design template for creating and maintaining sites that are much more loosely coupled? I'm not looking for small variations in MVC, I need something completely different to see, maybe some kind of plug-in.

EDIT:

Thanks for answers! Another way to express this is that I want the code to work better in my office. Do I A) Push for MVC or B) find / build an alternative that is not so confusing for semi-programmers. We already use classes for things like connecting to a database and using Form. The question for this question was to research B.

Answer 1

There is always a trade-off between confusing code, because it is highly deconstructionist, and the code is confusing, because absolutely everything needed to execute X is randomly scattered across one file.

The problem with the latter is that exactly what is an “intuitive” way to divide things into monolithic modules differs between people. Very decayed and factorized code is almost always harder to wrap around you, but once you do this, maintenance will be easy and simple. I do not agree that it bothers anyone other than the author, looking at him. Large-scale templates, such as MVC, are used because it is easier for them to identify them and work on projects structured around them over time.

Another advantage of using MVC is that you generally will not make the application more complex for those who come after you if you do not stick to the layers. This is due to the fact that now you have a predefined place where you can place any aspect of the implementation of a new function.

As for hard link, you cannot really implement a function without any link between the layers. Loose coupling does not mean that layers do not know about each other completely - it means that a layer does not need to know how other layers are implemented. For example: at the controller level, it doesn’t matter if you use an SQL database or just write binary files to save data at the data access level, just for that there is a data access level that can receive and store model objects for it. It also doesn’t care if you use a raw script or Smarty at the presentation level, just so that it can make some object available under some predefined names for it. While at the presentation level, you do not even need to know that there is a controller level - only it receives calls with data for display, ready in accordance with the above names provided by / something /.

Answer 2

As template templates, I believe that the MVC template is one of the most “loosely coupled” ways to build an application.

Think of relationships such as interfaces or contracts between parts of the application. A promises model to make this data available for presentation and controller. No one cares exactly how the model does it. He can read and write from a typical DBMS, such as MySQL, from flat files, from external data sources such as ActiveResource, until he completes his end of the transaction.

The controller promises to make certain data available for presentation, and relies on a model to execute its promises. The view doesn't care how the controller does.

The view assumes that Models and Controllers will retain their promises, and then can be developed in a vacuum. The model and the controller do not care if the view generates XML, XHTML, JSON, YAML, plaintext, etc. They hold their end to contracts.

And of course, View and Controller must agree that certain things exist. Viewing without any appropriate controller activity may work fine, but can never be used. Even if the controller does nothing, as it can be in static pages:

<?php class StaticController extends ApplicationController { /** * Displays our "about" page. */ public function about () { $this->title = 'About Our Organization'; } } 

Then the corresponding view can contain only static text. (Yes, I’ve implemented such things before. It's nice to convey a static look to someone else and say, “Just write on this.”)

If you look at the relationship between M, V, and C as contracts or interfaces, MVC suddenly looks very “loosely coupled”. Be careful with the bait of stand-alone PHP files. After you include and require half a dozen .inc files or mix your application logic with your display (usually HTML), you may have linked individual pages more freely, but there are issues with important aspects in this process.

 <?php /** * Display a user profile */ require_once 'db.php'; $id = $db->real_escape_string($_GET['id']); $user_res = $db->query("SELECT name,age FROM users WHERE id = $id;"); $user = $user_res->fetch_assoc(); include 'header.php'; ?> <h1><?php echo $user['name']; ?> Profile</h1> <p><?php echo $user['name']; ?> is <?php echo $user['age']; ?> years old!</p> <?php include 'footer.php'; ?> 

Yes, "profile.php" and "index.php" are not completely related, but at what price?

Edit: In response to your edit: click for MVC. You say that you have "semi-programmers" and I'm not sure which half (do you have people with an interface who are well versed in HTML and CSS but not server side?), But with some programming problems?), But with MVC, you can only give them views and say "work on this part."

Answer 3

I have to say that I really do not see your problem with MVC, since you are already using templates. I kind of consider it as a template that develops naturally when you try to add structure to the application.

When people first start developing a PHP application, the code is usually one big mess. Presentation logic is mixed with business logic mixed with database logic. The next step that people usually take is to start using some kind of template approach. Regardless of whether it is related to a special template language, such as smarty or just splitting the markup of a presentation into a separate file, it does not really matter.

After that, most of us find that it is recommended to use special functions or classes for the logic of access to the database. It really should not be more advanced than creating specialized functions for each commonly executed request and placing all these functions in a common include file.

This all seems very natural to me, and I do not think it is very controversial. But now you are already using the MVC approach. All that is behind this is more or less complex attempts to eliminate the need to rewrite commonly used code.

I understand that this may not be what you wanted to hear, but I think you should overestimate MVC. There are countless implementations there, and if it is true that none of them fits your needs, then you can always write your own and more basic implementation.

Look at it this way: since you are already using the template language, you usually need to create the first regular PHP file, and then the templare file every time you create a new page. MVC should not be more advanced than this, and in many cases it is not. Perhaps even you just need to explore more complex approaches to transferring access to data and add them to your current system.

Answer 4

The fact that you need to create a new Model and Controller action when you need a new page, I don’t think your levels of M, V and C are closely related. It is simply a separation of concerns and contributes to an unleashed system.

However, it is possible to focus on the intentions of MVC (and I worked on such an application) and make it closely related to the components. For example, a site might put a “rendering engine" directly at the controller level. This will obviously add more grip. Instead, a good MVC will be designed so that the controller only knows the name of the view used and then passes that name to a separate rendering engine.

Another example of poor design in MVC is that views have URLs hardcoded in them. This is the work of the routing mechanism. The view should know only about the action that needs to be called, and about the parameter that needs to be performed. The routing mechanism will then provide the correct URL.

Answer 5

Zend framework is very loosely coupled and very good. Check this:

http://framework.zend.com

This article may also be useful:

http://blog.fedecarg.com/2009/02/22/zend-framework-the-cost-of-flexibility-is-complexity/

Answer 6

You can try the Igniter code. It is very easy to recognize and does not strictly accept MVC, giving your code a good structure.

Answer 7

The code of Igniter and Kohana (a descendant of CI) is fine, but also free MVC. I like the simple php framework . This does not bother you, and it provides important things without forcing you to create structure or complex agreements.

Answer 8

Ah ... good old MVC arguments.

I need to support a multifaceted PHP application, pieces of which are written "MVC", but not all. Worse, different parts have different ways to execute MVC, all of which are homegrown. And some pages just do it all themselves.

The main problem is not that there is diversity in the framework code, but that the coders clearly do not understand how to abstract from the API. IMO, this is the biggest problem with MVC frameworks. Almost all the code I have to work with uses "models" as places to place functions. This is a nightmare to maintain.

To make this supported, IME you need a few things:

• An explicit and clearly defined level of data access, the API border of which searches for and stores persistent storage, is very small.

  I do not like to use the term “model” for this because it is controversial. No matter what calls at this level care about how the data is stored, you don’t even have to worry about things like database descriptors: this is all about the level of data access.

• A dispatcher that is very light and does not do any magic beyond just dispatching.

Now you can place everything else in one place that accepts requests and parameters, possibly normalized and checked the error from the dispatcher, retrieves the data (usually as objects) that he needs, makes the necessary changes, saves the data, needs it, hands, data must appear in the view. For this step, two hundred lines of code work that perform the task. You do not need to remove bits in functions in another file that are called from nowhere. You can even put a view at the end of this file! Idealism is nice to strive for, but pragmatism needs an appearance because it is supported.

(Okay, rant ...)

The lack of PHP for security means that the best frameworks do what PHP does: they stay away. Some of the most supported codes that I worked on had one require() statement at the top, did all the data manipulation with data objects (no SQL in sight), then output HTML surrounded by template functions, and the form control executed with consistent API function.