I'm researching a basic, stand-alone UI app that I want to be 'MVC compliant'.
My question is, what is the typical correlation of the three layers to source code files?
In other words: should I expect to see separate fooView, fooModel and fooController files, or are some functions (eg. Controller) typically specified declaratively and/or handled by a framework?
I realize there are a million MVC frameworks and that the answer probably varies, just looking for a general concept. Cheers and thanks.
Start with the server-side language that you have available and narrow down your MVC framework from there. I would stick with a framework that fits your programming style and needs. Yes, you should have three unique layers (models, views, and controllers) and they should not mix. I.e., in ASP.NET MVC projects you would find a controller, model, and view folder.
Related
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.
I want to make one mvc3 application which is student management.
I've seen some open source projects.
They have used solution structure like core,data serve rice.
is there any reason to use structure like this?
Usually it is a good a good idea to keep things separated.
By that I mean not mixing up business logic with database management code and having non-UI code in the view files.
This makes it a lot easier for others to understand the code you have written. I also helps you, when you get back to some project after some time to make improvements or correct errors.
I hope this answered your question, if not shot again.
Edit: I found this link explaining how it is done in the MVC framework.
Use layered architecture where you isolate each layer by using the Separated Interface pattern. For the database, use Repository pattern (easiest way to archive that is to use a ORM like nhibernate).
Use an inversion of control container to reduce coupling (with the help of interfaces) and make it easier to handle dependencies between classes.
As stated in the previous answers, you should separate your logical tiers into a minimum of BusinessLogic (Entities,validation,etc..), Data(your favorite ORM), and presentation (MVC).
However, if you are just starting out it may be a little daunting to incorporate all of the more advanced concepts of a SOLID architecture.
Separating logical tiers doesn't always have to mean separate projects. The standard MVC3 template demonstrates this with the "Models" folder. Any entity added to this will be under the namespace Myproject.Models. Later you could re-factor the code in the Models folder into a separate dll,add a reference, and as long as the namespace was still Myproject.Models the MVC app will continue to work.
The same thing could be done for your Data Access layer!
If you're just starting out I would recommend developing your app in the MVC project and separating your DAL and Business Layers with a Folder (Namespace). Once your application is working you can re-factor as needed.
I've recently discovered that MVC is supposed to have two different flavors, model one and model two. I'm supposed to give a presentation on MVC1 and I was instructed that "it's not the web based version, that is refered to as MVC2". As the presentations are about design patterns in general, I doubt that this separation is related to Java (I found some info on Sun's site, but it seemed far off) or ASP.
I have a pretty good understanding of what MVC is and I've used several (web) frameworks that enforce it, but this terminology is new to me. How is the web-based version different from other MVC (I'm guessing GUI) implementations? Does it have something to do with the stateless nature of HTTP?
Thanks,
Alex
It appears that MVC1 (model1) did not have a strong break between the controller and the view where as in MVC2(model2), these concerns were separated.
See if this gives you any more insight: MVC1 and MVC2 discussion
More InformationJust a little more
I Think this is the main difference between MVC1 andMVC2:
The hallmark of the MVC2 approach is the separation of Controller code
from content. (Implementations of presentation frameworks such as
Struts, adhere to the MVC2 approach). But for MVC1 did not have a
strong break between the controller and the view.
Model 1 Architecture: - Here JSP page will be responsible for all tasks and will be the target of all requests. The tasks may include authentication, data access, data manipulation etc. The architecture is suitable for simple applications.
Disadvantages: – Since the entire business logic is embedded in JSP chunks of java code had to be added to the JSP page.
For a web designer, the work will be difficult as they mite face problems with business logic.
The code is not reusable.
Model 2 Architecture : – The servlet act as the controller of the application and will be target of every request. They analyze the request and collect data required to generate response to JavaBeans object that act as model of the application. The JSP page forms the view of the application.
Advantages: – Reusability
Ease of maintenance.
Seems like every project I'm on uses a Model View Controller architecture, and that's how I roll my own projects. Is there an alternative? How else would one create an application that has persistent storage and a user interface?
MVC has been around for a while. It's a time tested and proven pattern. Many frameworks leverage the MVC Pattern. Martin Fowler has deconstructed the MVC into: Supervising Presenter and Passive View.
Architect Christopher Alexander said it best:
Each pattern describes a problem which
occurs over and over again in our
environment and then describes the
core of the solution to that problem,
in such a way that you can use this
solution a million times over, without
ever doing it the same way twice.
I'm not sure why you would want to move from MVC. Is there a problem you are encountering that MVC does not eloquently solve? To give you a better answer we need to know more about your problem domain.
Things to take into account when considering patterns/architecture: If you are building something with a Myspace type architecture you'll need a robust architecture (MVC). If you are creating a simple crud interface via the web - almost anything will do.
For .Net Web forms (I am assuming web, since you didn't say thick or web client) which is not MVC, it was a nightmare maintaining them. Web Forms applications that lived more that a couple years tended to become big balls of mud. Even then developers discovered ways to use MVC with web forms.
Ironically, the lack of MVC architecture in ASP.NET web forms was one of the driving complaints that lead to the development of ASP.Net MVC framework.
From experience if you don't use some MVCesk approach, your solutions become hard to maintain and bloated. These applications will die a slow painful death.
If your solutions are small one-off projects, the by all means throw something together. Heck there are tools that will generate everything from the screens to the data access layer. Whatever works to get the job done.
Classic CRUD apps built using tools like VB6 and Delphi have user interfaces, persistent storage and don't use MVC. Most of them used data aware controls linked directly to database fields
Couple of links comparing various MV* patterns which might be useful:WPF patterns : MVC, MVP or MVVM or…? & MVC, MVP and MVVM
Look into MVP model view presenter.
User interface is View and an application will always have a model and the bridge between the two is Controller. The whole MVC is nothing special as this is how the things will be always.
At the most you can get rid of Controller and have your view talk to your model but you loose the flexibility.
I've developed an alternative to ASP.NET MVC. You get the same loose coupling and separation of concerns but the difference is in how you go about building your projects.
I have a couple of videos on my blog, source code for the framework, a sample project and a few VS.NET add-ins (New Project item, New Builder and New View).
Builder for ASP.NET
Some key differentiating Features are
1. Templates are just html - no code mixed with templates
2. Templates are thus reusable across views and Web site designers can design templates in their design tool of choice
3. Strongly typed code (no ViewData and stuff) so you get intillisense, compile time checking, F12 navigation etc.
4. You build pages as compositions of views rather than an inside-out approach
5. View can be treated as "real" classes.
6. Everything is complied so no run-time compilation
Quite a few other differentiating factors as well.
In theory :
MVC is a proved technology and yada-yada-yada, and it is ideal for websites.
But in a real case:
A serious project that use MVC required a framework, hence you are following a framework with all their limiting and restrictions. So, at this point, the specific implementation of MVC is rule and not a simple "guideline".
Also MVC fail miserably for websites when it is about to connect to the model other than simple POST/GET, it fail with xml asynchronism and it fail with ajax. (*)
(*) exist some patch but a design must be clear and functional and if you need to "patch it" then it is neither clear nor functional.
Personally i think that the main problem with MVC is that it put so much effort in the Controller, where most project use not more that 5 lines for the controller part.
ps: Most "well done" MVC projects are 3-tier project.
ps2: MVC excluding some framework, is just a buzzterm, IS NOT A SERIOUS TERMINOLOGY and it is reflexed in the group of "interpretation of mvc".
What are your favourite patterns for writing a controller?
This is rather a tough question as MVC is applied differently in different contexts. For example, for a desktop GUI, you might have listeners for event notifications of view changes but such behavior typically isn't used for Web forms (AJAX is changing this).
For the Web, you generally have:
Model: business logic
View: presentation logic
Controller: application logic
The controller should generally be minimalistic and if you find yourself pushing display information or business rules in it, there's probably a design flaw somewhere. Classic examples of such flaws in the controller are building HTML (view) or accessing the database directly (model).
I've written up a more thorough description of MVC on my O'Reilly blog. I have concrete examples there which can help explain things a bit more in depth.