I was thinking about switching one of my projects (and after that subsequently other projects too) to Spark View Engine but after todays research I ran into problem of a lack of Intellisense for Visual studio 2010. Not only that but it seems that the project is not maintained regularly.
So I'm left with a feeling that I should not choose Spark at this time yet. However, apparently NHaml has the same "issues" too.
I know it is discussed in more detail here ASP.NET MVC View Engine Comparison
but I would still like you thoughts on what to choose or just stay with WebForms view engine for now?
I love Sparks, compared to the WebForms view engine. All views get so incredibly clean, compared to the normal one. Intellisense or not, I'd still take Sparks. Easy choice. You still get runtime errors when something is missing, and when you get used to not having Intellisense there, it's not that much of a problem. Debugging might take those five extra seconds, but hey - readability and clean views before marginally quicker debugging of (mostly) simple syntax-issues.
I've used Spark for a project through four months now, and I'll never go back to the default one. Never had any serious problems with it once you get the hang of it, and it's absolutely worth it. You'll know when you see it in action for real :-)
Related
I've researched this, but have yet to find a viable answer. I've run into serious problems when trying to upgrade to MVC 3. Without going into a lengthy explanation, I simply need to revert back to MVC 2. Due to restrictions in discussing work projects, I can't list all the "why's", but this is a requirement. I add this in because I saw a similar thread in which all of the answers revolved around why this should happen and suggestions to make changes so MVC 3 could stay. I can't do this.
I used the upgrade utility, so I assume many changes were made that I'm not aware of. I finally got the application to build after changing the project references to System.Web.Mvc version 2, but the page won't load, giving this error:
The view at '~/Some/Shared/View.ascx' must derive from ViewPage, ViewPage, ViewUserControl, or ViewUserControl
I can of course Google this and fix it, but I'm afraid that I'm going to encounter myriad build or runtime errors after doing it, and was hoping for an easier way to revert. Any help in doing this would really be appreciated.
As with any kind of upgrade, it's always best to plan in contingency for any issues that may occur, and back your work up prior to upgrade.
Hindsight, however, is not what you're looking for. Do you not have source control? Can you not roll-back to a previous date or change set? If not, you're pretty much going to have to go through every issue one at a time, and regression test your entire application. I don't know of any software that can revert to a previous major version (i.e. usually includes major breaking changes) without quite a bit of hassle...
Just bite the bullet and put it down to a learning experience, and make sure you get the project in to source control and implement a backup system ASAP. Even my personal projects are backed up to SVN on my NAS!
I'm thinking of experimenting with alternative View Engines for ASP.NET MVC, and would like to know what other people are using.
Please let me know 1) Which View Engine you use, and 2) Why.
The standard 'web-forms' view engine is of course a valid answer, but please say so only if you have decided to use it for a reason, not just 'Becuase I can't be bothered to change it' ;)
Thank you!
Most of the time, I use a 'standard' view engine - however, since MVC is so extensible, what happens is that sometimes we only need to inherit from it, override some little bit of functionality, and then plug it back in.
In addition, having looking at the Spark view engine, their particular style of making view code didn't gel well with me, but that's no fault of theirs - just different strokes for different folks.
The standard view engine has the most functionality in terms of both Visual Studio compatibility and ASP.NET MVC compatibility, but it's the least readable.
Spark view engine is usually preferred by most people, mainly because it has a nicer view, and it's mostly "compatible" with the designer crews, who only know how to create HTML pages. It also has some C# IntelliSense support for Visual Studio 2008. If you need to give out the view to designers Spark is the best choice.
Coming from the rails/merb world I actually prefer NHaml, because it's very expressive, and DRY, although it's not really "designer friendly". It also has some C# IntelliSense support too. (N)Haml is a view engine that people either hate or love because it's terse nature.
As far as i know these are the only three view engines that have support for C# Intellisense (and only for VS 2008, although work to get them run under VS 2010 is in progress), which can help a lot, and which usually people who want to switch from the "standard" view engine consider a "must-have".
Don't forget however that you can mix view engines in a project, so you can use the standard view engine where you need it's functionality but switch to spark/nhaml/anything else if they suit your needs better.
I've been implementing areas, but have found that it instantiates a development server for each area when it launches Cassini.
Is this really necessary? MSDN is having me setup these areas as separate web apps, Why can't I put them into class libraries?
Yes, you can get them down to class libraries. You may want to look into what the guys at MVCContrib are doing. They are calling it portable areas which gives you the libraries that you were asking for. They use their own Embedded view engine to get the views back out of the dll. Here is the link that walks you through the process.
After much research the answer appears to be "not yet". We're still in a preview release of ASP.NET MVC v2 so I've decided I should back off until they feel really good about it.
I thought I'd jot down my experiences for those of you interested in modularizing your ASP.NET MVC projects.
Currently, whenever you do a build it basically copies all of your child projects (created for the areas) into the parent. Which works after a build HOWEVER, once you make a change to your views in an area, the change doesn't show up until you rebuild. This one hurts agility and I know the team is looking at it now.
Because of this "disconnected" project structure, you do get some flagged issues (lost intellisense) in the view which we just typically ignore (like script references etc). Just remember it's one application in the long run.
Also, the issue with that posted above. You will have seperate dev instances when debugging but it deploys as one application.
Overall, there are options to "home grow" your own modularized solution (much like CWAB did) but I'd urge you to wait for the next "supported" preview. I feel really good about this team and their abilities. Perfecting areas will really make us satisfied.
In case anyone stumbles on this because they are still building Areas using multiple projects, you can definitely do this within a single project in MVC 2. With the single-project method, you get only one running instance when you start it up locally. There is an MSDN tutorial that can walk you through single-project Areas, but watch out for their area registration bug when you start unit testing it.
Since asp.net mvc did away with many controls that were in webforms, does this make rapid application development equal with other environments now? For example, if I have an mvc framework in php, j2ee, etc., and I have asp.net mvc, and the coder knows the given platform, isn't the development advantage gone in visual studio?
If I am wrong about controls being missing please let me know, it was my impression they were (and I couldn't use them when I tried it last.)
I ask because where I work some like Microsoft - a lot, some can live with it, but the ones that like it point to Visual Studio for rapid development. I thought much of that was gone with asp.net mvc 1.0.
EDIT: I guess I am thinking that dragging and dropping controls means Rapid Application Development (again, assuming the coder knows what they are doing everywhere else.)
Rapid application development is just a buzzword. It exists if you develop an application rapidly, not due to any particular tool or technology.
ASP.NET MVC is just a different approach. Some people can work faster when they are closer to the HTML. For me, this means I don't have to deal with the (IMHO) touchy databinding model of WebForms. Instead, I pass my Model directly to my View for rendering. That lets me develop rapidly. You can still develop your own UserControls (or download many of the ones that are available through open source projects), but you can't use anything that has events or ViewState intrinsic to it.
EDIT: RAD is also a subjective term. Is it rapid application development if you can churn out the first iteration in two weeks, but have to push the schedule back two months for the second iteration because the code was not maintainable?
If you are talking about the ability to drag controls onto a page, click them, set some properties, and have a code generated for you, and a working application by basically dragging controls and tools around, yes, MVC removes the ability to do RAD.
MVC exists to solve a different problem. It is for people that want separation of concerns to support unit testing and extensibility. Things that were nearly impossible to get with classically developed asp.net applications.
Web forms was an attempt to be more RAD if you will. However, the emergence of things like MVC, and Dynamic Data and things like Linq and Linq2SQL are pretty darn good evidence that Web Forms alone were not the panacea RAD platform.
From a personal standpoint, one may be faster at Web forms just by experience. That doesn't mean the platform or it's competitors are better or worse at RAD.
A lot of people found that Web Forms took so much control away and had such large event models that it ended up being less RAD than hoped.
I'd say that Rapid Development and ASP.NET MVC are not mutually exclusive per se. however since MVC has the intent of segregation of responsibility to (amongst others) allow testability, it might not be the best choice for Rapid Development-
On the otherside are ASP.NET Webforms where you can do ALOT "visually"/using drag-n-drop (i.e. no code), which to some extent does a very good job of for example preventing testability. But developing is a "no-brainer" - meant in the most positive way :)
Well, I've never considered Visual Studio as a RAD platform. Faster than PHP, sure. Comparable to Netbeans/Eclipse. Not even close to a true RAD platform though (oh Delphi, how I miss thee!).
Last week , my boss ask my team to evaluate ASP.NET MVC, for next project.
all of us working with webform since .NET 1.1, we have no MVC experience before ,but all of my colleagues are interested in ASP.NET MVC ,But no luck , our finally answer is NO.
Because:
We believe although you are ASP.NET Guru, you can build a complex application in short amount of time. But if you change to ASP.NET MVC, the development time will take longer, every things need to using html helper, no web control, and many question ,keep opening the Firefox Tab with ASP.NET forum for ask How-To question.
We had see many times people say MVC provide better project management , but if it is a complex web site, I can imagine there are hundred <%=%> TAGs in one page, and keep open controller to see what to return, and keep opening model to see the logic.
I can say , MVC is not bad, but Webform is strong enough to handle the job.
It will take several weeks to change over to a new technology, or a "way of thinking".
With MVC, you have to get away from old ASP.NET Forms way of thinking "complex web application" in that "how many pages we have, over 300 pages! that would be huge!". You change the view of your entire application. You shift from old thinking of "what page need to create next" to the MVC way of thinking of "what function do we need to implement next".
For example, I myself took control of a project that has over 3300 files in the 'web' project alone (plus the 11 supporting assemblies). One thing that I am architecting is how MVC will drastically cut down the number of physical files down to around 310 or so. How? Because I am moving away from "here's one page. Here's another page." to a "here's the function I want to implement" way of thinking.
By looking at pages as the function you are trying to accomplish, you instead start abstracting pieces of that page out into common functionality.
MVC can greatly scale with this way-of-thinking because now you have a template for the way you want it to look, you just need to implement another "function" to change the look of that View (html) you want to render. No 2nd page, no additional controls, etc.
Now, as for "no web controls" as you mentioned: again, this calls for a different way of thinking. There is the HtmlHelper that is used for basic rendering and encoding. I use the same concept with an abstracted class called MyProjectHelper that renders my "functions" onto the page (functions=code).
For example, I always created a Server Control for my DisplayNames in the past. This allowed me to control the way that DisplayName was shown, especially with a switch to Facebook Connect and other things. With MVC, I no longer use a "server control", but a "function" on a ViewModel to render that text: CollegeProjectViewModel.RenderDisplayName(). Since this is only part of the UI layer, this will render the Anchor as needed with any options I wish (of course, the abstract is inherited by the CollegeProjectViewModel that picks up on the "basic" text rendering).
MVC's power lies in the ability to no longer require a "webpage", but instead "functions" or methods of what you want to do with your site. By changing to this way of thinking, you really can scale with as many method you create on your Controllers. It really speeds things up on a mass scale IMO.
I worked on a MVC project at my last company for 6 months (we were using the CTP builds and eventually the beta builds). Initially, it was fun and exciting and it felt like we were really on to something. Like a lot of .NET developers out there, we were tired of the leaky abstractions of Web Forms.
However, as time progressed, we started to question our decision. The UI development was taking like 80% + of our time. We had to build all our UI from the ground up. Half the time it felt like we were reinventing the wheel. Most of our Rich UI came from JQuery combined with Custom HTML Helpers, which were fun to design, but time consuming.
There were other problems we were encountering, like the necessity of DTO-like objects to map from our business objects (fetched from a repository backed by NHibernate) to the Views. And our controllers, which were apparently supposed to be lightweight and easy to maintain, were becoming increasingly cluttered and we were constantly arguing about the proper way to implement controller inheritance.
In retrospect, I feel all the problems we were facing were due to our lack of experience and understanding of MVC. We all liked the idea of MVC, but just didn't have the practical experience and know-how to use it effectively on what I consider to be a very complex (imagine something along the lines of Sales Force, but with better reporting) application.
-- UPDATE --
Been using it the last month to work on a very small project and so far things are going smoothly. It's much easier to work with than the CTP versions I was using a year ago. I am currently looking at my own personal solution for complex "grid views", and then I might switch over completely for most projects. However, Dynamic Data has been treating me proper and I am sort of torn between the 2.
-- UPDATE 2011 --
After several various sized MVC projects over the past year or so, I have become somewhat of a convert. All the real issues I had with it have mostly been resolved in the latest versions (2 & 3), particularly the ones dealing with model validation and binding to and from views.
One thing though: it still can be a bit tedious to create highly interactive data grids, something that is still somewhat easier in WebForm. However, there are 3rd party offering that provide useful MVC extensions making this less of a concern. Personally, I use Telerik's offerings to great ends.
Among many benefits to using MVC is the removal of the viewstate hog.
If your Webform app is really large and uses a lot of server-side items that bloat your line with viewstate, then MVC may actually help you, even though it may take longer to develop.
On the flip side of that, be on the lookout for .NET v4.0 which will allow you to control viewstate on the control level instead of just on the page level. That will make MVC even less palatable overall.
I think you're right that it will take your team time to adapt to the new technology, and this will take extra time in the short term.
I wouldn't start using MVC in production until are some decent books out and the team has had a chance to read the books and play with the technology. Otherwise it seems your dev team will spend a lot of time watching screencasts and fishing for documentation.
I came from webform development (just like you), from 1.0 up until 3.5. When I discovered MVC (CTP), it took me about 6 months to convince my peers (and my boss) that it is the way to go.
Some of the highlights of my arguments:
Full control of HTML
TRUE AJAX (instead of update panel)
Possibility of using jQuery exponentially increased
No VIEWSTATE
Separation of concern
.. and .. (drum roll) ... faster development
Although #6 is a little bit subjective, but I did try to prove it by building prototypes. For my prototype, I built a simple dashboard web app, using both webform and asp.net mvc. I showed my peers and my boss the result, as well as the complexity of building and maintaining each one. In the end, we migrate our main methodology from webform to MVC.
It is true that it takes a while to "unlearn" some webform paradigm. But once you get it, MVC is so much easier to pick up and you can run with it.
In webform, yes it is powerful, but often in large projects, we spend a lot of our time trying to "customizing" or "coercing" a server control to behave and perform like the way we want it - and as complexity of the system goes up, the complexity of this customization also goes up exponentially.
TRUE AJAX is also quite difficult in webform. UpdatePanel has its role, but nested update panels has its own share of problems as well.
For me and my peers, it boils down to the ability to control our HTML/code/AJAX - instead of automatically generated 90% by the framework but we have to spend a lot of time and effort to get the rest 10%.
ASP.NET MVC, combined with jQuery, and your prefered biz tier framework or ORM, is extremely powerful. So far to date, we have released 3 production releases with ASP.NET MVC and they all perform well - heck take a look at stackoverflow.com (it uses MVC btw).