Could someone explain me about MVC pattern? How does it help cakephp framework?
MVC stands for Model, View, Controller.
Model = Data (Database tables)
View = HTML, CSS, JavaScript, etc
Controller = Main logic, a contract between Model & View.
In simple and graspable terms,
MVC allows you to develop your applications in a way that your business data and presentation data are separated. With this, a developer and designer can work independently on a MVC app without their work clashing. MVC makes your app avail OOP too.
Have a look at the respective section in the cookbook.
Related
So I've been reading/viewing a variety of tutorials about MVC. I am most familiar with building MEAN stack apps, and but am now a little confused on how I thought the MVC worked.
From my understanding in a MEAN stack app the MVC is like: the view is HTML/CSS, the Model is JavaScript(Data and logic of storage objects), and the Controller includes the Controllers, Factories, and Services? (This is where I'm mostly confused). But then I saw a tutorial that explained the whole client side to be the View, the server was the Controller, and the database was the Model.
Does this mean the MVC pattern can be applied to the front and back end of an application? If so, then a MEAN stack app has two MVCs?
As I understand it, usually the MVC pattern only applied to the front end of an application.
May be this website can help you more : https://evincedev.com/blog/mean-stack-architecture/
Angular doesn't have MVC architecture. It follows MVVM (Model View ViewModel) architecture. Usually in MVC a database acts as a Model, Server acts as a Controller and front end is the View.
In Angular Controller is replaced by ViewModel. ViewModel acts as a connection between the View and Model. View is written in html files, Model is usually written in Services, ViewModel is written in Controllers.
To my understanding, MVC is a way to implement the separation of presentation tier from business and data tier. Am I understanding this correctly? If so, MVC should separate the business logic completely from presentation, right?
So to me it seems like javascript (or jquery) is somehow violating the MVC design since it takes over some of the logic on the client side, isn't it? Is model = data tier, controller = business tier, view = presentation tier? I think I have misunderstood the whole concept.
You seem to have a decent understanding of MVC. The trouble is that you are looking at two different potential MVC structures as one and the same. On the server, you can have data models, controllers, and views. On the client side, you can ALSO have data models, controllers, and views. If you want to look at your client side JavaScript as MVC, then jQuery is simply a utility that the view controllers can use to manipulate the view (the DOM).
Simply put, the client side doesn't always have to be only the view. If you use a web application client-side framework like Backbone, for example, then you can have models, views, and controllers all on the client side, which communicate with another, SEPARATE MVC structure on your server.
What you describe does actually pose a challenge for a lot of implementations. Frameworks such as the ASP.NET MVC Framework have been making attempts to auto-render JavaScript to the UI based on business logic in the middle tier (validation rules for form fields, primarily). But they're a long way off from having a truly compelling JavaScript user experience which doesn't repeat logic.
Personally, I like to think of the JavaScript as purely a UI concern. The application internally handles all of the logic. The JavaScript, as part of the UI, may duplicate some of that logic... but only for strictly UI purposes. Remember that the application should regress gracefully into a still-working state if the user has JavaScript disabled. That is, it should still use server-side (middle-tier) code to get the job done. All the JavaScript did was add a richer user experience to the UI layer.
JavaScript isn't the only culprit for this, either. Suppose you have a lot of validation logic in your middle tier defining what's valid or invalid for your objects. When you persist those objects to a database (which is on the periphery of the application just like the UI is), doesn't that database also contain duplicate validation logic? Non-nullable fields and such.
Congratulations! Your understanding of MVC is completely wrong. It has nothing to do with n-tier architecture (which is what you seem to be confusing it with).
The core idea of MVC is separation of concerns. This is used by dividing the application it two major layers:
model layer: contains all of the domain business logic and rules.
presentation layer: deals it user interface
The presentation then is further split into controllers (for handling the user input) and views (for dealing with response).
When applied to web applications, you either have MVC (or MVC-like) structure only on server-side, or, for larger and more complicated applications, you have separate MVC triads for both frontend and backend.
Also, when working with applications, the user of MVC is not human being, but the browser.
In latter case the backend acts like one data source for frontend application. An the whole frontend part of MVC is written in javascript.
P.S. In case if you are able to read PHP code, you can find a quite simple explanation of model layer in this answer. And, yes. It is the "simple version" because MVC is a pattern for enforcing a structure in large application, not for making a guesbook.
You can go to http://www.asp.net/mvc site and refer tutorials / samples to learn about MVC using Microsoft technologies.
So the way I've always worked with MVC in .Net is to create ViewModels for each View.
Now, with using Knockout, would I create my ViewModels in javascript instead of a C# class? And then have my main Model(in this case, EF generated Models) as my only C# Model classes? Or would I still go about create a C# ViewModel class along with my Knockout ViewModel?
I'm trying to set this project up DRYly, but I'm not sure of best practices in this situation.
You can create viewmodels (VMs) for the C# server side and still have them intended for the ASP.NET MVC Views. Then create VMs for the client side javascript views too. But the way I;ve liked it best is to use the MVC Views as the basis for the page, and have the Models be the basis for the JavaScript models. The only VM would then be the JavaScript VM since most of the presentation is really done client side. In other words, do the more static plumbing in MVC, then do the dynamic interaction client side.
If you are building primarily using client side JS libraries like KO I would not start with a VM for the MVC side unless you have a strong reason for it.
If you have specific questions, I'd be happy to try to help.
Create view models as you always do.
Create a HTML helper which generates a KO view model from it.
You should base your Knockout viewmodel on the view data from the server in order to at least have it initialized with data from the server without having to make a separate request to get that data.
You can optionally use the mapping plugin to map the view data to your viewmodel.
I am trying to migrate to zend framework. Should each webpage be a Controller or an action.
What is the advantage of having multiple actions. Can they talk to each other? and whats the best use of Action helpers and View helpers.
Please guide me on how to start on the framework.. thanks
You can use a new controller for each page or define multiple actions on the same controller to render your pages. I choose to use defferent action from the same controller to display variuos pages. Using multiple action on the same controller allows you to put some code in che constructor of the controller that is executed for each action. For example i have a controller for all the pulic pages of a website and a new controller for those pages that are reserved to registered users. In the constructor for the controller dedicated to registered user i do the check for authentication.
You should check that page about MVC applications, It's not precisely related to Zend. But you seems to be asking what a MVC Design Pattern is.
You got to create a controller for each of your site's pages. If any page interacts with db, you should also create model for that page. Also you should create view for each of your page.
If you have no idea about MVC, you can read this:
MVC
Those links are from Zend Framework manual.
Do not afraid and click - read the Introduction chapters - you will have all answers. ;-)
View helpers
Action helpers
Action Controllers
First get a sound understand of MVC Framework:
Understanding MVC Architecture from its Origin (part I)
http://learnnewprogramming.com/blog/understanding-mvc-architecture/
I'm just browsing MVC examples so far, and I think I'm getting a handle on it. For my project - an embedded system on ARM9, no Windows/ASP at all - we are considering doing all the UI as MVC. Does MVC also require a strict Tree of all UI Views (one root?)
No, one controller may have different views for different actions.
You can split the controller into a front controller and several actions.
As reference see The MVC Pattern as implemented into Symfony framework.
If your views are parts of a full page you might also use the same view from different controllers. Ie header and footer.
A controller can have many views and partial views. If you take a look at some simple ASP .NET MVC tutorials: http://www.asp.net/mvc/tutorials/mvc-4/getting-started-with-aspnet-mvc4/intro-to-aspnet-mvc-4 you'll learn how this can be done easily.