Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I will start a new .Net MVC project with a small team. It have five members, two back-end devs and three front-end devs.
The front-end members will work separately, building a html version of this project using tools like gulp/grunt, less/saas, jade and others frameworks. They prefer to use editors like Sublime and will run interface tests in many differents devices in real time.
They not able to work with MVC specifically Razor view engine, so we need two repositories, one to front and another to back.The back-end developer in the process ever need to catch the built html and suit it in Razor MVC.
Any ideas how to improve this process? How can i reduce the technical gap between back devs and front devs?
IMO you are trying too hard to accommodate the skills/desires of your team members. You will not get good cohesion from the client side with the server side if you completely ignore Razor/CSHTML. Your overall architecture/design should come first, and dictate these decisions. Of course you would take your team's skills into consideration, such that you wouldn't make a team of Java developers adopt C++. But you are taking this to an extreme by basically throwing consideration for design/architecture out of the window, and saying you will divide the application based on what your devs are willing to work with.
My opinions aside, you can make this work, but somewhat painfully.
For one, developing HTML apges first in a vacuum without consideration for interactions with the server is either going to result in very crippled interface that is more like static website from the 90s. There are a few cases where you can build a single-page-application that's pure javascript with no AJAX requests, but these scenarios are very rare.
Therefore, you need to either build the server-side first, or have a design step that mocks up the page and talk through how it will work.
1) Design a page and it's features, and how it interacts with the server. Identify what interactions are navigation actions, such as clicking a link to navigate to another page, versus those which are AJAX operations. Do NOT implement HTML, that comes later. As a team review what each dev mocks up and make sure they've thought through all of the interactions thoroughly.
From this, list what server side operations are needed in the controller for that page:
agree upon URLs
is it GET/POST
is it AJAX
whether it returns a page, partial HTML fragment, or JSON.
what parameter names for each are and data types
2) Your backend developers create controllers, exposing actions based on agreed upon design. CSHTML will for now be stubs and return nothing.
3) Your frontend developers create HTML/javascript to consume these.
They will be able to point ajax operations to the controllers, but they will need to mock what is returned since the Controllers don't know what HTML they should be returning yet.
4) Front end devs provide HTML to back end devs to incorporate into the project so that actions/partial views return the HTML or HTML fragments.
The problem is you are going to constantly be iterating through frontend devs giving HTML to backend devs to incorporate into the MVC project so that the actions that return HTML and or AJAX actions that return partial HTML fragments (PartialView) can be tested.
It makes for a very non-agile process.
You won't be able to take advantage of many frameworks for MVC which assume you are using Razor views/HTML helpers. Many frameworks for compressing/bundling javascript/less/css which integrate well with MVC are not going to be viable. You can still do this stuff, but you'll have a workflow that is not as smooth and will involve more hacking it together yourself.
I would like to point out that almost all javascript frameworks work great within CSHTML. From the client side perspective, MVC/CSHTML doesn't introduce any strangeness that prevents you from building very interactive pages. You can build a CSHTML page that is pure HTML and javascript, and makes AJAX calls to controllers, but trying to take that outside of the MVC project is going to cripple the development workflow. Designing and implementing an interactive page requires alot of consideration for how the actions on the server side are implemented.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
As we know, MVC in .Net supports two view engines, namely, ASPX and Razor. I have read several articels and have observed that Razor is unanimously(almost) considered as a better option between the two. The reasons being:
Razor is clean - Agreed. The syntax itself makes it cleaner.
Razor syntax is simple - Agreed. There is no need to close the tags.
Razor is light-weight - I am unable to understand why is it considered light-weight ?
EDIT 1
Other differences:
- The design can be viewed in the ASPX engine while it cannot be viewed in Razor engine.
Also, apart from these differences, are there any other differences which make Razor and ASPX significantly different ?
If I am missing any other basic difference/point here, please point it out since I have been able to summarize only the above after reading several articles.
I think "lightweight" might be a reference to the output from the razor engine: thinking about the output from a traditional aspx forms app the server delivers a page with not only the markup but the viewstate as well, control ids are bulked by effectively a path which describes how they are nested on the page and then there is all the javascript which makes this and things like postback work. In addition updates to the page are more likely to involve a round trip to the server (they needn't but most often they do). On postback the server also has the job of serialising and deserialising not only the viewstate but also instantiating all the controls on the page before you can code against the dom. There are optimisations that you can do but essentially your going to end up with something that looks a bit like this and all of this could be described as heavy - heavy payloads to the client, heavy workload on the server serving the pages and servicing the pages.
In contrast the output from a razor built form can be little more than the markup - simple HTML controls a few hidden fields for key values etc and a button or two. You can add CSS and jquery and dynamic dom manipulation but they aren't essential for making the page: a submit button a form with an action and a method will get your form data back to the server and that's all the server gets a collection of basic encoded form fields. The server will instantiate the expected entity type based on the form fields (it needn't) but that's all it has to do before your coding against the posted data.
In this way the razor model could be considered lighter than the trad aspx way. Even complex pages tend to push the processing to client via javascript/CSS/jquery libraries and ajax communication.
Main advantage of Razor view are :
1) optimized syntax for HTML generation using a code-focused templating approach, with minimal transition between HTML and code
2) Supports layouts (alternative to master page in aspx)
3) Unit testable (Most important in large projects)
4) Supports IntelliSense.
5) The Razor View Engine prevents Cross Site Scripting (XSS) attacks by encoding the script or HTML tags before rendering to the view
6) Razor has a syntax that is very compact and helps us to reduce typing.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've been in some discussions lately and the talk is about moving over to ASP.NET MVC and Knockout for future work on a product that is currently ASP.NET web forms. This product has many of the characteristics of the general current definition of a SPA.
I've never quite seen how MVC actually fits in when you start generating all your views with JS view models which get their data from calls to JSON web services.
Is there a "sweet spot" that leverages the best parts of Knockout w/JS models and JSON and the MVC framework?
Here are some things that I've been thinking about this (a little random - just seeing if I can spur on some discussion/answers):
When would you use Knockout vs. Razor? Knockout generates the view elements at run time on the client browser. Razor runs as part of the server request before the client receives the response. Are there times that one is clearly better than the other or does it come down to personal taste?
Is there value in keeping more code under the guise of C#/Razor for the purpose of code completion? Also, when exceptions get thrown, stack tracing to compiled code seems easier than JS debugging.
Is it better to completely separate the view from the back-end by creating a blank ASP.NET application and an independent Web API project?
Lots of great questions, I'll share some of my thoughts on the subjects. (Questions have been paraphrased):
1) Is there a place for MVC in a Knockout world? - Absolutely. MVC is a lot more than just Razor. Server side routing, Areas, Authentication, and more, are all provided by MVC. So in my mind, I can still use MVC for all the "admin and organization" but still have all my Views be primarily (but not necessarily completely) AJAX driven. I have discussed using MVC and KO together on SO before. I also have a video dedicated to that topic at WintellectNOW dot com.
2) When should I use Razor? - Let's actually switch up the terminology. It really isn't about Razor vs. Knockout: it's really about server-side vs. client-side rendering.
So when should you use server-side rendering? One ideal time for this is when you are loading data that only has to be done once when the page is initialized. For example, if you have a list of States for a drop down, and that list is extremely unlikely to change, go ahead and load that on the server side. Why turn around and make another request back to an API in that case? I would reserve those calls for dynamic or context sensitive data.
3) Is there value in keeping more code in C# for tooling purposes? - IMHO, no. It's true that debugging JS can be painful, but that is not enough justification for me to disregard all the awesome things I can do client side. It's worth the occasional frustration to provide a better user experience.
4) Should I move Web API to a different project to keep the code separate. - It completely depends on the needs of the project. If the Web API project is going to service multiple applications, then YES it should be in a separate project. That will also put it on a separate DOMAIN, SUB, PORT, or something to differentiate it from the rest of the Web app. Doing so introduces Cross Origin Resources Sharing (CORS) issues. CORS is a particular hell I wouldn't go through unless absolutely necessary. If your Web API is only going to service your single web app, do yourself a favor and keep it in the same project.
As with everything else, a lot of this comes down to personal preference. Mine is to use Server side for managing the bigger picture of my app, and client side for all the UI/UX.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Personally Coffeescript is ok, but I would rather it be a supporting player in my Rails app, not most of the logic. From what I can see, you still have to duplicate a lot of the logic when using Backbone.js or Spine.js in Rails. Can I not get the benefits of these frameworks or make what is essentially a single page app with js for real time updates using just rack-pjax?
Well what do you want to achieve? No more page refreshes? In that case rack-pjax should work. If you want more speed or a responsive UI then I'm afraid it won't be a good solution.
A single page app is preferred imo because it seriously decreases the load and complexity on the server + there is a nice abstraction between viewlogic & serverlogic.
Your server would basically be an API and your client would render all of the API data to the browser. This way the server is heavily simplified and has a lot less work to do. (win!)
On the client side we can also see a lot of improvements. If done right it rerenders itself continuously based on events and statechanges made to the data. This approach leads to much less coupling (and duplication) in your UI layer and a more responsive UI for the users. (win!)
If you don't care much about that then go ahead and use pjax :)
Keep in mind though that rewriting an existing server-side-view-rendering app to a single page app using a JS frontend is tricky business. It'll probably end up in a major rewrite. You could also experiment with writing just parts of your page in a JS frontend.
While rack-pjax does prevent the browser from refreshing the page with each request, the server is still sending an entire HTML page with each request. If your goal is a "single page" app with no page refreshes, rack-pjax will work but you're going to save a lot of bandwidth and have a much more responsive app if you use a framework that deals with JSON instead of loading an entire page.
For a simple app, I'd recommend starting with something like Backbone or Spine. For more complicated apps, you'll quickly find yourself writing a lot of boilerplate code with those smaller frameworks and you'd probably be better off letting something like Ember or Cappuccino handle most of the heavy lifting for you.
If you want a single-page app, it's a given that some or most of your logic is going to be on the frontend, either written directly in javascript or written in coffeescript and compiled to javascript. Of course, you do still need certain logic at the server (like validations.. always assume, even with validation logic in your JS code, that people can and will send bad data to the server).
I was wondering this for quite a while and haven't really found an answer for this yet.
Why would you use Backbone.js exaclty inside a Rails application? Is it to extend functionality, have a more MVC pattern for your JS, build better API's...?
At the moment I can't see a reason why you would want to use it for something, because I don't think I understand the concept of Backbone.js
The big advantage of rails is that you have one platform and one language that you use that will handle the server-code and can generate the client-code (using the views).
Undoubtedly this theoretical advantage quickly starts slipping once you want to improve your user-experience with javascript and jquery. So actually you still have to learn two languages.
But still: all your models, business-rules, ... is handled on the server-side in Ruby. This also means that the server always has to be reachable.
What a javacript/client MVC (like Backbone.js, Sproutcore, ...) can offer you is a more native application feel. A single web-page application, like e.g. Gmail.
Depending on your requirements there are some very valid use-cases for such a platform. E.g. in places or devices with low connectivity it could be very useful (with HTML5) to have a web-application that does not need to be "online" all the time. It could save data and edits to the local storage and sync back to the server/database when the device is back online.
But, there is a big disadvantage when developing client MVC applications in combination with Rails: you will have to do some double development (it is the same when you are using flex/silverlight). Your models will need to be defined both on the server and on the client. I can imagine that some improvements could be made, like on the client MVC you are actually using presenter-classes, which on the server-side could be stored in different models/tables. But still there will be duplication of logic, models, ...
So that's why I think that for most applications, at the moment, it is not wise to switch to some client MVC framework. It will be a lot more work.
But when you do need the look and feel of a real native application, or a one-page-web application, then a javascript client MVC framework is the way to go. And if you do need a client MVC framework, I would propose Sproutcore.
To simply ajaxify your current rails application (reduces load-time of every single page), take a look at pjax-rails.
(better late than never - hope this is useful to someone)
The description on backbonejs's website seems like a lot of words thrown together without much meaning. There is a big hype around it but what's all the fuss about?
The premise behind backbone is that modern day, single page web apps (think gmail) quickly become a very complex interaction between syncing dom elements, UI events and the backend. You could easily find yourself storing data within the dom elements, and then having to somehow extract the data again to update the database. If you don't structure your code very carefully, you'll quickly end up with spaghetti code full of complex bindings, or code without backbone.
Using backbone's models, collections and views gives you a well thought out structure to work within, allowing you to build large apps without being overwhelmed by their complexity. What's more, it ties in beautifully with a restful backend.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
I am trying to teach ASP.NET MVC to students (undergrads) that have been studying ASP.NET for the last 8 weeks (I know that doesn't sound like much time, but the class is 4 hours per day, 5 days per week with Labs, Quizzes, Exams, and Wrestles).
I haven't gotten the question yet...but I know it is coming...
When would I use MVC instead of ASP??
I don't have any real experience with ASP MVC and I can't find any sort of clear-cut answer on the web. Arguments such as "...the web is stateless and ASP MVC is a closer match etc etc" do not mean much to them. They are starting to notice that ASP has lots of controls that seem to simplify their markup compared to MVC.
I'm trying to give an honest spin, and any feedback would be much appreciated!
TIA
Statelessness is a good one word to explain as already highlighted by the members.
Apart from this ask the following questions to the students?
If they have to do the following with ASP.NET (no MVC), how easy will it be?
Test your views
Mock Http objects.
Viewstate reduction (by design)(
Substitute lightweight viewengine for .aspx.
Thorough separation of concerns.
Clean HTML
etc. etc..
Now explain asp.net mvc in the above context. There may be more to it.
Atleast I think they will get the point, thought this may not be applicable to all project, but what's the harm if we are only gaining from this.
To me, the MVC approach is a very different paradigm from the ASP Forms API. I think the idea of being "stateless" is a good way to explain a very broad topic in one word actually.
One of the major advantages that I've seen is that the MVC framework gives a lot of control over the design and the output of your page. For small projects, this may not be the best use of it, but for large projects, it scales very well because you can make different architectural choices that (personally) I find to be better, such as the way that the MVC framework separates logic from the view.
Also, if you're designing a site that has a lot of Javascript, the control you gain over output in the MVC framework can be very helpful because you don't have to worry so much about how IDs and other markup may be rendered, like you typically do in the ASP Forms framework.
The MVC framework is really a totally different way to design web sites. Personally, I think it is more beneficial for large projects, but I also started out in web languages where MVC was a more popular design choice to begin with.
That's just my 2 cents.
I always thought the ASP.NET MVC Framework was a bad name since its a Design Pattern.
The question should be :
When would I use ASP.NET MVC Framework over ASP.NET Web forms?
The Developer Experience
a) ASP.NET Web Forms tries to abstract away the stateless nature of HTTP from the developer. The state of GUI Elements, and or data is stored in the Viewstate/Session. Everyone Form does a postback to itself, basically mimicking the behavior of a WinForm event driven design.
b) HTML GUI Elements are further abstracted by Controls which can be re-used, bought from 3rd party vendors. This helps developers glue an HTML app together without to much JavaScript and HTML/HTTP Knowledge. Basically similar to the way you would develop VB / WinForms
c) You can do a good job implementing the MVC/MVP pattern in ASP.NET webforms. Look at the Patterns and Practices Web Client software factory to see how they did it.
d) Developing using WebForms you are generally changing the HTML (View) based on user feedback at the server. Most events (user clicks a button, edits a field) are handled at the server in a continuous postback loop executing whats called the ASP.NET Page Lifecycle.
VS
Browser controlled view (dont know what else to call it). All changes to the HTML based on user input is handled in the browser. You will be manipulating the DOM with Javascript.
Note: I basing this on the fact that ASP.NET MVC is most likely driven by basic HTML + Ajax
How I would personally choose between them (never having used MVC, just reading on it)
1) If I was to build a pure stateless front end using Ajax, Jquery, EXT JS type libraries ASP.NET MVC would seem the better fit. Although you could build this in ASP.NET Webforms it seems pointless since you not taking advantage of the Postback model and Server Controls.
2) If I were asked to build a new basic web application, I would stick with ASP.NET Webforms since i'm already familiar with it and know the whole page lifecylce.
3) If I were asked to build a Web 2.0 (hate that term) to have a next gen User Experience, I would probably go with ASP.NET MVC, and use JQuery / ASP.NET Ajax client controls.
4) Many companies have built up a solid set of WebForm controls to use. It would be costly to rebuild them all in a pure stateless ajaxy way :)
For someone with experience (and pains) in Winforms - the biggest difference is no more Viewstate. The state of controls on the form is kept on the client, in the browser and sent to the server for each request.
If you use Javascript, it is easier to make changes on the browser side, while the server side gets an easy way to look at the form as a whole without having to recreate controls binding.
Beyond all the nice things MVC provides - separation of view/code, testability - this was for me the key point to move to MVC.
Apart from all the other excellent responses already listed. Webforms is an abstraction away from HTML.
When you want a html table of data, you put a "gridview" control on a page - what you end up with is "gridview" html, and quite possibly not exactly what you were after.
The shoe fits 90% of the time, but a lot of the time, especially when things move beyond a basic site that the controls don't fit. Using Webforms often means that you don't have full control over the final output that is rendered to the browser.
You can of course extend, or write your own grid control. But wouldn't you just prefer to write the html you want instead?
It's my experience that has the projects get more complex, and UI's get more complicated that you end up fighting webforms more and more often.
http://www.emadibrahim.com/2008/09/07/deciding-between-aspnet-mvc-and-webforms/