I'm working in a Banking Online Platform written in WebForms and I'm wondering if the same could or should be written in MVC.
I've read a lot on MVC but i didn't tried yet but i must ask a question for the experts.
Every transaction has a 3 Stage Process where the users input the data, review the data and gets a 3rd step where get's the confirmation. I currently have 40+ processes like this. The way i do it? Single ASPX with MultiView.
How can i do the same in MVC? Would i have 40+ x 3 Views (120+ aspx) ?
Thank U all.
The same can be achieved in MVC by using partial views.
MVC has full control over the rendered HTML and JavaScript frameworks is much easier to implement. It is also a lot more easier to write unit tests.
It is also 'lighter' in the sense that it does not have any View State events (which is the thing that makes Web Forms big when working with big data)
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 have to start a new project, a webapp with lots of forms and screens and i really don't know which technology fit best. The application is an ERP like app, with very few animations and lot of forms. The goal is to reduce at minimum reloads and waiting time, it has to be as close as possible to a normal desktop app (a lot of work to look like a marvelous VB6 app :-)
On the one hand we have client side MVC (backbone). It's cool to have all the code running on client but in my mind this implies repetition of lot of code (for example all models definitions) from server (PHP + Fuel). Sure once loaded all the informations task like paginations or grid work without any delay but it also present some problems of synchronization (other users can change data and i have to manually invalidate data on client).
On the other hand we have pjax. The idea is to make all the templating and so on on server, just implement a logic to return the page without the frame for pjax request or full page on new requests. No code duplication, very simple client side.
I've read the the story from basecamp and from twitter and both the point make sense to me. You can't relay on visitor computer (features, performance ...)
The more i think about it the mode i like pjax over MVC, but maybe i'm missing something. Which are the MVC advantages over pjax or pjax disadvantages over Client side MVC ?
Thanks a lot
Backbone.js is good for heavy, single page web apps that never truly post back, but have lots of ajaxian things going on, interdependent cascading dropdowns, etc. It has a very good API for events and collections. If you have plentiful client side javascript, it can be a helpful way to organize it. It is opinionated in the sense that it expects your server-side architecture to be RESTful by default, and you have to make some effort to use it for non RESTful APIs.
The project I'm working on is an ERP web app as well, with asp.net MVC on the server-side. I've learned that Backbone (with handlebars as the templating system), and .net mvc really don't play together that well. If you go Backbone, you really have to go full-hog (controller methods serve up json, that's it). On pages in this app that are more or less 'normal' web pages with some forms, Backbone is the wrong choice.
I just googled pjax for the first time, so I've basically just read the short description at the top of the page, but I suspect that might be the way to go for your scenario, in keeping with Keep It Simple Silly principles.
Here's the situation. We're adding a new application to our suite of webapps based on WebForms and so I felt this would be the perfect time to introduce MVC.
I did all the research about intermingling the two and got the project all set up using an Area that uses MVC routes while the rest of the (visual studio) project runs with web forms the way it's been running.
Master pages were converted to Razor layouts, not too bad because there was only one master page that was shared between every application.
The problem I've run into now is reusing user controls. We have dozens of custom user controls, many of them fairly complex, that are reused throughout all of our applications. Most of them (especially ones that would be difficult to port) do a fair amount with ViewState and postbacks.
If it were just a matter of rewriting these in MVC, the one time cost would be less than ideal but not terrible. But since the existing apps need to be maintained and updated as well, it seems like maintaining 2 versions of the same behaviour using entirely different paradigms would be a huge drain on productivity.
My gut says there isn't really a good solution and we may have to abandon the idea of going to MVC for this project and stick with webforms, but I wanted to see if the SO community has any insight on what to do in this scenario.
If you have the budget to rewrite those server side controls using the MVC paradigm that would be the best way to go. If not, you could still embed them into existing classic WebForms pages and which would communicate with the new MVC application using standard HTTP/HTML techniques: form posts, sending ids through query string parameters, iframes, cookies, HTML 5 storages, etc... One thing's for sure though: try to avoid putting those server side controls in your MVC views. You will end up with some hybrid application that is neither proper ASP.NET MVC nor a proper WebForms which would be a disaster.
Personally I had to do this same migration multiple times and I didn't bother mixing classic WebForms with MVC in the same application using Areas or some other techniques. At the end of the day it might turn into a nightmare trying to make those two exist together. It's always one of the two: I have the budget and I rewrite from scratch properly or I don't have the budget and I do the new stuff properly using ASP.NET MVC and try to interact with the existing application.
I find it easier to simply start a separate MVC application which depending on the interaction I am looking for would use different methods for integrating functionality from the existing WebForms application.
I am not quite familiar with the complexity and details of your scenario so it is difficult to provide an objective answer but the possibility of continuing to write new code based on the existing WebForms server side controls and not doing any MVC at all for this project might also be a good solution. Writing a new application on ASP.NET MVC just for the sake of it might not always be the best choice.
I'm currently diving into web development after ten years of desktop development and I'm trying to get a high level grasp on the many concepts I'm learning. The two most recent concepts I've been reading up on are MVC (specifically ASP.NET MVC) and AJAX. I understand MVC is a pattern used to separate logic and data and AJAX is a combination of various web technologies for creating asynchronous and dynamic web pages.
How are the two related?
Can or should the two be used together?
If so, can you give some simple examples?
I apologize if these are strange questions and I'm comparing apples to oranges, forgive me as I'm still a huge gigantic noob.
Ajax is just of way of requesting data : generally, with Ajax, instead of requesting a full HTML webpage, you just request :
either a part of the page (say, the HTML code of one part of the screen you want to refresh without reloading the whole page)
or some data ; using JSON or XML as data-exchange format, for instance
MVC describes the stacks used to :
Access the data and do actions / calculations / whatever on it (M)
Present it (V)
Going through the Controller, which determine which Model and View should be used to serve the data you requested.
When you use an Ajax request, you do exactly as you'd do serving a full page :
get a request
determine which Model and method should be called
call them (maybe they'll do something with a Database, or whatever they have to)
pass the data to the View, which will render it
The two differences are :
The "View", in one case, renders a full HTML page : in the other case, only a part of it, or some JSON / XML format
In one case, the request is generally done in asynchronous mode
Ajax or not, you are free to use MVC... or not !
If you are using MVC for non-Ajax request, then, why not do so for Ajax requests too ?
Sorry, I won't give any example of code - I'm not a .NET developer, so won't be able to help with that (but the concept is the same in other languages ;-) )
I'll bite...
They're not related in any way other than they're both web concepts. Ajax is a method of performing an HTTP request and handling the result. MVC is an architectural pattern for building your web application.
Yes. No matter what architecture you use for your web apps, you should use Ajax where it makes sense. Ajax can increase the performance of your app, and improve the user experience and UI by eliminating bloated data transfer and screen flickering/refresh.
You can use Ajax easily through a number of javascript frameworks such as JQuery. Simply download and include the framework .js files in your application, reference it from your html, and read the documentation on how to make Ajax requests.
How are they related?
I'm assuming you're taking this from the POV of an ASP.NET dev.
It's really just because plain Ajax (+JSON) works much better with ASP.NET MVC than ASP.NET Webforms. Because of the way ASP.NET Webforms muddled together the view and the controller (and not to mention having Postback & Viewstate -- its crutch to allow pre-Ajax pages to overcome web statelessness), this was initially very difficult.
The way ASP.NET server controls cannot be directly (or at least easily) accessed from Javascript practically made it impossible to use conventional Ajax until ASP.NET Ajax UpdatePanels came along (which was, IMHO, another crutch).
With the advent of ASP.NET MVC it's now much easier to use straight Ajax libraries and JSON for ASP.NET web applications.
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".