Many PHP frameworks claim that they implement MVC design pattern. However, in their implementation, the model and view don't know each other and each communication in between must be done through controller. As I read in wikipedia, this is MVA (Model View Adapter) instead of MVC design pattern approach because in MVC, model and view communicates directly.
Those frameworks' claim are wrong or did I miss something?
Frameworks like CodeIgniter are MVA, yes. However, their claims are not wrong since MVA is basically a different type of MVC deployment. Mediating controllers are hit by users which handle the business logic; they also call to the model to get the data and prepare the view.
This is not wholly diverged from strict MVC where the Model and View can talk to each other, so to say it's "wrong" is a bit harsh. I would say it's a different take on MVC.
EDIT:
See CodeIgniter's take on it:
https://www.codeigniter.com/user_guide/overview/at_a_glance.html#
Models are not required as everything can be done in the controller (not advised, obviously). Note that CI (and most other frameworks) say they are based on MVC principles.
Related
I have been glancing at a RESTful specification available on http://restfulobjects.org (direct link to spec here). It is a little different from other things I have seen, but it makes sense, and having examples and clear specifications makes my development a lot simpler.
According to the standard, the URIs will be like:
api.example.com/object/user/31
api.example.com/object/user/31/properties/username
api.example.com/object/user/31/collections/channels
api.example.com/object/user/31/actions/someFunction
api.example.com/object/user/31/actions/someFunction/invoke
See this answer for a brief explanation of the structure. It is quite clear.
Note: This is not a discussion whether or not services/actions can be
represented as resources. There is a good discussion on that topic
here: http://www.infoq.com/articles/Intro_Restful_Objects. Look towards the end of the comments section.
My project is still on the drawing board, and most design elements up for grasp. I will however be using Symfony. I have my entities, and I have some services that act on those entities, and I have controllers to define what the services will do in a specific context.
And so to my actual questions:
...the Restful Objects spec is not based on the MVC pattern - it makes
no assumptions about the architecture of the server that implements
the API. In the URL:
~/objects/customers/31/actions/lastOrder/invoke
the 'actions/lastOrder' is not specifying a controller action, it is
specifying an action (i.e. a method) on a domain object (customers/31)
How do I structure my controllers in the most efficient way if I want to use the specification in an MVC application? Considering that the controllers would somehow serve different resources (objects, services, domain-types) as well as different representations of that resource. What are my layers?
Update Do I have e.g. a customer controller? An generic object controller? A useraction controller?
Do I need to rethink my whole entity/services approach? i.e. the solution for how to implement this is beyond the controller structure? (I fear it is, and then I do not know my next step)
For simplicity/efficiency I would like to make use of the FOSRestBundle and NelmioAPiDocBundle. I believe this can be done, but I then am concerned the spec will only serve as a url template for me, and not being implemented in my logic/design since I have to massage my framework to fit the URL somehow.
Please excuse my ignorance if this question has an obvious answer. I am new to RESTful APIs. If it comes down to a subjective perspective on implementation model, please give me some pointers, because I am currently at a loss for how to approach this.
From the "What is Symfony2 ?" article of Fabien Potencier:
Is Symfony2 an MVC framework?
If you look around, every single framework seems to implement the MVC pattern. And most of them are advertised as MVC frameworks... but not Symfony2. Have a look at the documentation, and you will see that the MVC pattern is only mentioned once or twice, but Symfony2 is never defined as being an MVC framework.
A bit later in this post:
Symfony2 is an HTTP framework; it is a Request/Response framework.
That's the big deal. The fundamental principles of Symfony2 are centered around the HTTP specification.
...
Sometimes, you just need a way to create a REST API. Sometimes, the logic is mostly in the browser and the server is just used to serve data (think backbone.js for instance). And for these projects, you don't need an MVC framework. You need something that handles a Request and returns a Response. You need a framework that implements the HTTP specification. HTTP streaming is yet another example that does not fit well with the MVC pattern.
...
And if you like to call Symfony2 an MVC framework, then you should know that Symfony2 is really about providing the tools for the Controller part, the View part, but not the Model part. It's up to you to create your model by hand or use any other tool, like an ORM.
As Symfony is a set of components, you can easily adapt your usage of the framework to the project you are working on, and the principles that you want to follow (here a REST specification).
The FOSRestBundle is very extensible.
You can define your routes manually, create different views of your objects through serialization.
Plus, I think you can keep very light controllers by writing the most of your objects management's logic inside Repository classes.
So,
Use simplified models and serialization to have different views/layers of your objects.
You should not rethink your whole Entity/Services in order to be more REST, just give them some changes/improvements in order to use them through data-transfer objects/domain objects (models) and Repository classes (fetching/storing methods).
You should be able to take benefits of use REST utilities such as FOSRestBundle, it provides more than built-in actions, allows you to make all custom stuff that you could need, be MVC or not, and be REST or not. It's at your own appreciation.
Have you considered using either Naked Objects (for the .NET platform) or Apache Isis (for the Java platform)? Both of these give you a complete Restful Objects compliant restful API for free - derived entirely from your entity models. (I am responsible for the first of these two. Our implementation is built on top of the ASP.NET WebApi framework. We have a RestfulObjectsController, with many methods on it, but these are all generic methods, corresponding to the various Restful Objects resource types - we do not need to add any new methods specific to the domain objects or their actions.
I've been learning Yii2 framework for a couple of weeks now. One of its core concepts is "Fat models, thin controllers". Reading the source code of the advanced application template I found that due to this concept nearly all the logic is contained within the models.
Well, there could be no questions at all if I hadn't some experience with Spring MVC where service layer seems to be a kind of natural way to decouple application's logic from its actual data.
So the question is: can it be a good practice to implement such an enterprise-like structure in an application built with Yii2? Speaking more specifically: is it worth breaking Yii's models into Entities, DTOs and Services?
Thank you in advance!
P.S.: The question can seem to be a kind of too abstract or subjective but having little experience with Yii2 I'd like to know are there any architectural features in Yii2 that could make the above mentioned implementation be not optimal in regard to code maintenance, performance and so on?
You can actually create models that are not ActiveRecords, so they actually become your service layer, just need to extend from yii\base\Model or yii\base\Object as you see fit, and implement all the logic you need there. You can also create those models on another folder called services, so their namespace would become app\services\ModelName
Using another feature instead of built-in feature can not be a good practice for every framework.
IMO, the model part is a killer feature of yii2, so if you do not need scaffold (code generation), you can use any other php framework without model part (zf2, symfony2, micro-frameworks).
So you can use your own model architecture without any perfomance lag but you'll need to write more code to make things done and your models will be hard to support by other people that are using yii2 and therefore I recommend to use another framework which comes without model layer.
Does MVC really means you have to separate => View aka design (html css) => controler (php code), model (mysql code into classes etc.)???
Are there not alternatives? Wondering because I would really like to avoid separating php code and mysqli as right now it's sooo easy to work on it (got used to it).
Yes, you definitely want to separate HTML and CSS from business logic.
Most frameworks use an ORM or something similar to abstract building queries but still give you the option to write plain SQL. I would recommend to use an ORM like doctrine2 for example over plain SQL. If you use any SQL directly the model would most likely the right place to put it into.
MVC exists for a reason, separation of concerns. This makes sure that your application becomes easy to maintain because every part of it should be easy to replace and not depend on each other to much. You want to avoid strong coupling. MVC is a pattern that helps you with that.
And like tttpapi said, there other ways to do it, but honestly, I personally think that specially Wordpress for example is a horrible clutter. I don't like Drupal or Joomla as well. The code base feels like working with 10 year old clutter compared to a modern well written application following the MVC pattern.
This is a little about discipline es well, I've seen totally messed up applications as well because people did not pay attention to separation of concerns and didn't follow the MVC pattern.
Does MVC really means you have to separate => View aka design (html
css) => controler (php code), model (mysql code into classes etc.)???
No.
MVC is about separation pf concerns. It separates presentation layer from model layer. And within presentation layer - it separates handling of input (controllers) from handling of output (views).
The model in MVC is not a databases abstraction or collection of queries. Instead it is a layer that contains several groups of classes. The major groups are domain objects, data mappers and services. The model in MVC is all these things taken together.
Longer explanation: here
Note: do not confuse MVC's model with domain model, which is the accumulated knowledge and vocabulary for specifica application. The part of domain model, that can be encompassed in code, is implemented using domain objects.
View is not html and css. Views in MVC are classes that contain the UI logic for the application. THey acquire data from model layer and then, based in this information, choose which templates to use for producing a response.
Longer explanation: here
Controllers are not some mystical "php code". They are part of application that takes user input, and based on that alter the state of model layer and (in rare cases) state of current view.
Are there not alternatives? Wondering because I would really like to
avoid separating php code and mysqli as right now it's sooo easy to
work on it (got used to it).
The point is NOT separating SQL from PHP.
The separation of concerns principle simply means that each part of your application should be dealing with one specific aspect.
And, if you try to implement MVC architecture, it will NOT mean that you separate sql from php, but that you separate business logic from persistence logic. Both of those would be written in PHP. But the trick is - MySQL is not the only form of storage. Data can also be stored in session, in cache, in noSQL, in files, in SOAP, etc. If you have separated business logic from persistence logic, then you can add caching to your existing application without rewriting the whole thing.
Also ...
There are more architectures then just MVC and Big Ball of Mud (which was advertised by people who talked about Drupal and Joomla).
You have MVP, MVVM, n-Tier, DCI, EDA and many others. And all these will be adhering to SoC principle .. but the result that they come up with will be different.
P.S.: If you actually want to learn about MVC, I would recommend for you to start going through materials from this list. It will start by introduction to simple concepts and gradually build up to ideas that you have to grasp to actually start working with MVC.
It is always up to you.
You always can find way how to use MVC as nonMVC. (example is Joomla here you can use just view with all code in it)
Or you can use systems that are not MVC bases such as Drupal.
But the MVC is here for some reasons.
To directly answer your question, yes MVC means exactly that.
However MVC is just a design pattern, and not a holy writ.
There are many variations available to you. I myself initially thought MVC to be restrictive and confusing, but in fact it was the particular MVC based framework i choose that had these failings.
There are many lightweight, flexable frameworks available. Take a look at https://github.com/bcosca/fatfree as a nice example, in particular the database section. You wont think mysqli is simple in comparison
This is more or less a framework-centric version of a past Stack Overflow question, which is about how most introductory material on MVC applications tends to present a tight coupling between models, views, and controllers. For example, you'll have a User table that is modified by a User controller which in turn pushes filtered data to a User view. It's my impression that a lot of MVC frameworks tend to reflect this pattern as well. This is all fine and well for what it is, but it never really leads me to anything beyond building and displaying monotonous lists of things with an HTML form.
The MVC framework that looking at right now is Lithium, which seems quite interesting as a case study of clever PHP5.3 coding techniques. On one end, Lithium has a Model class that offers wrapper objects around a individual tables, and abstracts away some simple queries. On the other end, it's got a nifty convention of routing URLs to method calls on controller objects, which then render to display templates.
But in the midst of this, I find myself at a loss as to where to place all of the interesting logic that relates data in table A to data in tables B through Z. Or at least, I'm not sure where to place such logic in a manner that's consistent with the design of the framework. To my understanding, Lithium's Model abstraction doesn't do much more than eliminate some row-level insert/update/delete boilerplate, and the controller/view architecture seems mostly about user interface. I wouldn't want to put a lot of business logic in the same Controller class that is receiving routed function calls from URL requests.
My instinct would be to fill the gap with a bunch of my own code that exists more or less entirely outside of the framework. I'm not sure if I ought to expect more than that, but given how rigidly structured everything else is in Lithium, it feels somehow unsatisfying, like I could have just rolled my own boilerplate-reduction code without the overhead of grokking the source of a big framework.
What am I missing here? Is there a recommended architecture or philosophy to using this type of framework?
One thing you have to remember with Lithium is that theres no production ready release yet (although some sites are using it in production).
The main missing feature right now is model relations. With relations in place i assume your question would be partially answered as that is an important brick in the big picture of creating more complex applications.
You could check out the x-data branch where the work on relations should be ongoing.
For the second part of writing domain logic the simple answer is "in the model".
See this (rather useless) example of extending model functionality for example.
Another example to look at is the open source mini application Analogue that is one of the few working open examples of Lithium in use. The Analogue model class shows a slightly more meaty model.
And finally its a matter of connecting the dots between M, V and C.
A Lithium controller should mainly delegate jobs over to models, and perhaps restructure the input data if needed.
The simple examples of having a Post model, PostsController and views/posts/add,index,etc doesn't mean that you have to merely have Post::all() in there.
PostsController::view need to load a set of Comment models probably.
So you will toss a lot of your own code in there, of course! Else it would not be much of an application. But keep the domain logic tied to the model where it is natural.
Need to verify that blog post has a
unique title? Write a validator.
Need to ensure the user has write access to the post? Override the save method and verify it, or filter it.
But I think we need to wait for relations to land and a 1.0 release before we can fully judge how structuring applications in Lithium can be solved best.
at the moment im integrating ORM (doctrine) into a MVC framework (codeigniter).
then it hit me that this was the obvious way of setting up a MVC:
the controller calls the models that are representing database tables.
look at this picture:
MVC + ORM
then i wondered, how can a MVC without ORM be real MVC? cause then the models are not real objects, rather aggregations of different functions that perform CRUD, then returning the result to the controller. and there is no need for a state (object properties) i guess so the functions would be all static?
correct me if im wrong on this one.
i guess a lot of people are using models without ORM. please share your thoughts. how do your models look like?
MVC is a general purpose UI pattern originally conceived for OO languages (I believe Smalltalk was the first).
If you don't have a relational database as a back end (say, a binary serialized file format) you have no need of an ORM layer.
The two are quite distinct and can exist without each other.
MVC has nothing to do with objects. That makes it quite simple to have MVC without an ORM.
What about applications which don't use a database but use some other serialization for their data (such as writing out an XML file)? MVC and ORM are orthogonal concepts. MVC is about how you organize your internal object interactions, and ORM is about how you serialize and deserialize the model. You can certainly use MVC without ORM by simply substituting a different serialization method.
The controller part of MVC is not about making the low-level calls to serialize, it is about tying together views and models to create the proper user experience and task flow.