I'm in the process of designing a solution for the company I work at (but have just resigned from) which has a very complex application process in it. The process is close to 10 steps (including T&C's and preview) and also has some very tricky UI-level business rules (mostly driven by a legacy tie-in system).
Essentially the validation is driven by what has been selected on previous forms, and not just the one directly prior.
The solution has already been decided as an ASP.NET application but the more I design the solution the more it's looking like it's going to be very difficult to achieve in a stateless environment. It's going to either end up with query string parameters, hidden variables on the page, viewState or session to pass the information around.
Then I had it suggested that I look at Silverlight, to give it a more stateful environment and make it easier to handle the passing of the parameters around.
I've never done anything with Silverlight, other than watch presentations, so I've got no hands-on experience with it, but from everything I've read I think that it does have potential to solve some of the major problems which I can see coming out of trying to do this with standard ASP.NET.
So how do I go about:
Is Silverlight a viable option considering what I mentioned above?
Pitching Silverlight to a company without any Silverlight skills?
How do you deal with the "but it requires a browser plugin" argument?
From what you're saying your problem is about keeping state between multiple pages/forms. Sessions are good for that (not so much the query params or hidden variables as those can be tampered with, just having to think about that possibility when developing your app will slow you down.) I'd recommend that as simplest all round.
However, you can also put several forms on one page and submit them together, but have it look like different pages using javascript. It wouldn't be too hard to do with any decent javascript library, but I recommend jQuery (Microsoft is adopting, over their own, as the standard for ASP.NET)
Same as the silverlight problem if your company doesn't have many skills in javascript, but at least it doesn't require a plugin.
Don't get me wrong, I love silverlight, I love it so much that when it gets market share similar to flash, I'd drop HTML/css/javascript. It just doesn't seem to fit for you though.
I currently work for a company that builds its primary LOB app in Silverlight.
Silverlight may be a good choice for what you are trying to do, but consider:
Using Silverlight won't reduce the complexity of the application.
If you're already comfortable with ASP.Net, you can deal with complex workflow using existing idioms (Session state, the wizard control, or plain old CLR objects of your own that implement a decision tree/state machine model).
If your problem is really an issue of workflow design, you can integrate ASP.Net apps with something like Windows Workflow Foundation. However, "won't reduce the complexity of the application" probably applies to this, as well; in my limited experience, Windows Workflow Foundation hasn't made building workflows simpler, either.
What you gain by having state all wrapped up in local client objects will most likely be smaller than the cost of learning Silverlight and its idiosyncrasies.
That being said, there's nothing wrong with the idea of attacking this kind of problem in Silverlight. It's just not a silver bullet or anything; Silverlight has its own data access headaches, quirky UI code idiosyncrasies, and requires wrapping your head around yet another model for developing applications.
Silverlight has a Page class that enables you to easily support navigation where you can go back to the previous page as you do in your browser. I think Silverlight pages and the navigation framework is very suitable for the kind of application you have described.
Using Silverlight enables you to create a very rich client experience. Doing that is probably also possible in ASP.NET to some extent, but I find all the moving parts in a traditional web application (HTML, CSS, JavaScript etc.) and their interactions much more complex than the Silverlight model. If you don't have experience using Silverlight you could create a simple page navigation prototype without any real logic to get a feel for the experience. If you are satisfied you could then show it to management to demonstrate the power of Silverlight. If they like eye candy you could change the visual theme of your application in an attempt to impress them. This tactic may backfire, though, if management actually prefers battleship grey.
Related
I am not starting an argumentative discussion here and this post is not about career development, but from the commercial point of view:
If a company was using ASP.Net MVC as a main methodology to build their web sites and application.
However, ASP.Net MVC takes more time to show a functional application than ASP.Net Web Forms, for example, building domain models would take some time which obviously can't be represented on a UI at that current stage.
My question is, if a client wants to see a functional demo application (just a proof of concept) so he knows that the company he is dealing with is professional and capable of doing that. Would it be better to do that demo in ASP.Net Web Forms only to show the client, and then work on the real application using ASP.Net MVC? If not, what are the (quick) alternatives?, I mean, if we tell the client to wait till we have a working demo (by ASP.Net MVC) we may lose the client and the whole project opportunity.
WebForms being faster than MVC is a myth:
You are not required to have a domain model, just something that represents your database tables. This is the same in WebForms unless you are using SqlDataSource's.
The code in your !IsPostBack or btnSubmit_OnSubmit is almost identical to the HttpPost controller actions. Except with MVC you don't have to write left to write object.FirstName = txtFirstName.Text when you understand how UpdateModel works.
UI is UI. If you know HTML/CSS creating the UI is just as easy. Almost easier in MVC because you don't have to set control properties any longer and all UI can be done in one place.
Fast MVC comes from understanding how to get the most bang from your buck using EditorFor, DisplayFor templates. You'll need to know and understand how to customize your Object.ascx file. With this technique under your belt you won't have to create forms by hand anymore. 2 projects ago we had a site with 100% autogenerated forms. Change a class, change a form. Done!
Another helpful MVC tool is the DataAnnotations attributes. Validation made easy. Customizing these is really easy too. Just create your own ModelMetaDataProvider and starting expanding the validations your application can handle.
The only part of MVC that is slower is displaying a grid. MVC 3 already has a useful grid tool and MVCContrib has had a grid tool out for a year now. I ended up rolling my own, its very simple actually, loop through properties, write <td />'s. < 200 lines of code. This isn't really a benefit to WebForms either. To use WebForms grid components means giving up a lot of quality using ObjectDataSources and the like.
To summarize fast MVC comes from these different techniques:
Object.ascx
ModelMetadataProviders
UpdateModel
DataAnnotations
If you are more advanced and know ORMS like EntityFramework and how to use Automapper your probably going to be even faster.
You can get a demo up and running very quickly in MVC. I could put one together much quicker than with WebForms, and I am familiar with both.
The reliance on convention in MCV will help a lot, binding is based on the names of objects.
If i was creating a quick demo, i would just create a bunch of ViewModels with static data in them, different button clicks etc will just bind one of these ViewModels to the page.
Turbo Fast!
I build prototypes in excel. No logic, no code. just basically screenshots to show the user that we are communicating the same ideas. Create a worksheet for each "View" or screen you need to show. Client's usually only care how "pretty" an application looks vs does it work right.
This also is a benefit as you can include more non-technical users in the prototyping process, since most are used to excel. I can send you an example and the finished production web application, if seeing is believing. I personally learn best by example.
And to your post where you wrote...
I mean, if we tell the client to wait till we have a working demo (by ASP.Net MVC) we may lose the client and the whole project opportunity.
They need to have their expectations adjusted and managed. A lot of bad development has been done quickly over the years, which makes client's ask questions like "Bob did it in 1 hour'. To that I say, you can either have a lousy project fast, that you have to constantly duct tape or a well thought out and well written project that will only need to be enhanced as Bus Reqs change
I think the answer is obvious: use whichever you think makes you faster. There's no point in using MVC if you are faster in WebForms. Especially since this is for a throw-away demo.
I'm building a Bridge game.
The main page, where you play the game, boast some 200 controls, like buttons that represents the 52 cards, 26 others for won / lost tricks, plenty of text fields... You name it, total some 200.
Actually its been already built and runs under Winforms model, but with the unavoidable question of implementing .NET 4.0 onto user's machine that must run Windows, and installing the software.
Hence I'm considering creating an ASP version (no PHP please, since I'm fluent in VB, and ignorant in C, Java, PHP and the likes).
Is that a "real" option or am I dreaming?
Will it run smoothly for users with a 2MB DSL connection?
Oh, by the way, no MVC please, I'm too old for that sort of sh...t :->
Can it be done? Sure.
The problem for you might be that to do it effectivly you will need to use HTML, CSS, Javascript and the like.
What most likely would be a good idea for you here would be to go the route of Silverlight. It will give you a more rich UI experience and will allow you to code in VB entirely.
I don't see using ASP.BET directly as a good option here. To make it look smooth, you would have to use javascript heavily. I thing you would be better off with Flash.
If you prefer to use pure HTML/Javascript/CSS you can create rich Web UI's by modifying the Document's Object Model (DOM). With little knowledge of Javascript and the usage of some library like: scriptaculus, prototype, sarissa, jquery, you can get rich interfaces. You should take a look at some of these libraries mainly scriptaculus because the set of animations it provides. Another javascript library made for game development is gameQuery.
With that many controls on an ASP.NET page your view state will be gigantic. If you plan on only serving up a couple of games at once then it shouldn't be a problem but you have to actually start thinking about bandwidth with that large of a viewstate. You would be better off with a DOM/jQuery type interface which displayed static images for the cards. All interaction can be handled client side and validated with a server side call.
This might be the perfect opportunity to learn javascript :). Remember each language you learn is another tool in your toolbox. The engineer with the most tools usually wins :).
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
What’s your choice for your next ASP.NET project: WebForms or MVC?
Can you list some reasons that would make you use ASP.NET webforms for a new project, instead of MVC? I've heard a lot about the opposite, but not things that are done easier or better with webforms. I'm not talking about developer preferences here, but rather technology features and how they map to project features.
The only argument for WebForms is the need to design highly complex (read cluttered) interfaces with a whole lot of interconnected elements which in all or in part should react to changes in other elements.
A typical example would be some enterprise application (from SAP or smaller vendors). They usually have interfaces bordering madness. You'd have a hard time trying to synchronize the controls manually with JavaScript if you were on MVC. With WebForms it's by far easier.
Whether it is a good idea to build such interfaces is another matter entirely.
In WebForms element events trigger a page postback. They go to the same url and are processed in a unified manner. This is what makes the architecture very scalable.
With MVC to accomplish this you would have to set up a bunch of service urls to handle posts from different controls, then process those posts and update view models accordingly. This all involves a lot of trickery and juggling. Not that it is not doable - it is, but not on a big scale. This approach would not be scalable. Sooner or later you will arrive at the understanding you'd need to build your own framework in the direction of stateful object-oriented HTML/HTTP abstraction like WebForms.
A few things that could push me (back) towards WebForms:
I need to produce something that can be taken over by someone who isn't primarily a web application developer (say a WinForms programmer), and the app could substantially be maintained through Visual Studio's Forms Designer. The IDE support makes the development model closer to that of WinForms.
An app that needs to look Ajax-y but will be maintained by someone who won't learn JavaScript. I think things like the UpdatePanel (while horrible in so many ways) are actually pretty good for that scenario.
Possibly for some kind of demoware, again because of the IDE and ASP.NET AJAX. Fairly quick to knock up some reasonably smart screens without too much thinking.
I need a powerful CMS and need to stay within .NET. At this point it looks like there's better choice in WebForms than in MVC (though hopefully that's changing).
I'm working with a team who are already familiar with it and aren't going to learn MVC.
Of those, probably the CMS is the requirement I could think of right now that would actually make me use WebForms.
If you only know webforms MVC comes with a learning curve so you will need to spend quite some time training (or risk making serious security or performance errors)
You need a tiny little app NOW It probably is quicker to build a throw away mock application in webforms if you go for the anti-pattern. E.g. SqlDataSource, Logic in your code behinds etc.
Rich controls GridView is an excellent control, having sorting etc all built in for you with little code needed as long as your custom requirements are small.
Lack of web development experience Web forms is just easier. It takes more concerns off your plate. Much better for a newbie as its tough to go wrong.
Having said that, if you know what you are doing or have the time to learn and you want to build a long lasting site, MVC is soooo good. And more fun too.
I'll add that there is nothing really wrong with web forms. It's perfectly possible to build high performance app with it. It's just times have changed since it first came out and MVC has addressed those changes well.
Personally, i find MVC very good for admin-pages. because they usually have a load of tables, and are made for data input and editing. MVC is 'made' for those things, so it's going very fast making those pages.
webforms I use for more complex things, like the User-end of the site. the site i make shows courses people can take. the registering for a course is a 5 step procedure, which in MVC, I have no real idea how to do it. I'm sure it can be done in MVC but I think it's better/faster in webforms.
however in the end I do like MVC more. It feels so much cleaner to work with.
The only time i would consider going with Web Forms in a new project is if there was a component created for Web Forms that solved a specific problem that would be much harder to solve using MVC.
I can no longer see any advantage of Webforms over MVC, apart from some upskilling effort which should not be prohibitive.
[Originally I believe MVC wasn't compatible with webcontrols, so wishing to use Dundas chart control for example wasn't possible. That would have been a good argument for using webforms depending upon your requirements. But I believe this is no longer the case, and anyhow, you can include webforms in your MVC project as a worst case.]
It depends!
The difference between WebForms and MVC is if you can TDD and control the complete markup.
Easy question. I used to develop websites back in the days of "classic" ASP, and when I'm asked to do a quick and dirty website for family or friends now, I still resort to direct HTML/ASP and some basic CSS and Javascript - I can get the sites up pretty quickly this way. However, I've had a few requests to design and develop some sites for pay, and thought I should catch up on my web skills. I have been using .NET 3.5, XAML/WPF, etc. for Windows apps, so I'm up on .NET, I'm just behind on the web end.
To the question: If I want to design/code a site that looks identical on all (at least somewhat recent) browsers and platforms, should I be using ASP.NET and AJAX? There might be a little database activity on the site, but not much, so I don't need an enterprise level, multi-tier extendable architecture... just something that looks good and works on multiple platforms without having to code all variations for each browser. After looking at all the ASP.NET books at the bookstore, it seems they all focus mostly on data and postback stuff. Is it still a legit option to use some basic, boring html and javascript with some Flash embedded where needed?
Let me know if I need to clarify the question. Thanks for your advice in advance!
Your question is more loaded than you think, but let me try to address a few points that I think are relevant.
First, how a site looks is almost completely dependent on the HTML/CSS you use and how you code the front end of the site and only slightly dependent on the server technology. So if you want your site to function across browsers and platforms, learn to code following web standards, with semantic markup. (Search on those terms for more info).
Also, ASP.NET comes in two flavors now: ASP.NET MVC and normal ASP.NET. I highly recommend, if you are going to get into ASP.NET, that you follow the MVC platform. It closely follows similar technologies (like Ruby on Rails) and will make the transition to other MVC platforms easier on you. Also, the MVC platform doesn't try to output as much pre-made HTML as straight ASP.NET will when you use their "drag and drop" controls.
Secondly, it really depends on the sites you are building, but straight JS (or JS + jQuery), CSS, and HTML -- and please don't use Flash unless you are embedding a video -- will actually work for a number of basic sites. If you need some things to happen on the server, PHP makes for a great platform. If you are working with advanced database access, and program flow, and since you are already familiar with .NET, then stick with it... MS has some great tools and resources to help you out.
Finally, a lot of developers use a favorite CMS or blogging platform as the backend of simple sites that still need the ability to manage the content easily. Expression Engine (CMS) and WordPress (Blog/Lite-CMS) are often used (both PHP based) but there are tons out there.
Good luck stepping up your game!
I would recommend learning jQuery. This will give you a browser independent abstraction for your JavaScript.
ASP.NET controls will render it's controls in a browser independent way, but that doesn't mean your site will automagically be browser independent. You still need to know how elements are rendered differently in different browsers.
I'd also recommend using a CSS Reset sheet as a starting point for your CSS.
All in all, if you've been developing old school ASP, you'll probably really love ASP.NET as it will save you a lot of time and looping. You may want to jump right in to ASP.NET MVC too.
To the root of your question, I'd learn ASP.NET if you're doing anything more than a simple brochure site. If you have .NET experience, and classic web development experience, then learning ASP.NET is not going to be a big hurdle and will be well worth the effort.
I agree with Aaron Daniels' answer about learning jQuery. jQuery helps a lot with cross-browser compatibility in JavaScript and some CSS-based effects.
However, you should also look into ensuring your site uses well-formed, valid HTML, and doesn't use too many CSS 2+ features. This should ensure that your site is standards compliant, which will mean it will play well with Firefox, Safari, Opera, and even later versions of IE to an extent. You will still need to do manual tweaking for IE - it's been too broken for too long for MS to be able to fix it properly in one go - so look into conditional comments for applying a separate stylesheet for IE users.
AJAX is a handy technology for "desktopifying" your web app. It provides a mechanism for asynchronous callbacks to the web server, so you can pass data to and fro without reloading the page in the browser window. This is how the voting buttons work on StackOverflow, for example.
Lastly, ASP.NET doesn't really have much effect on the end user's experience in terms of the look and feel of the site. It is a server technology that provides for writing complex applications to be delivered over the web to a browser. Having said that, MS have put in some extra goodies to make working with AJAX a little easier.
Hope that helps!
I have read several other posts here, so i get the idea on the pro vs. cons, especially having full control over the rendered html code etc. (in MVC).
My question is regarding the UI controls: In MVC, i will have to write all UI controls myself (or the html equivalent). Now is that not going to be very difficult?
The reason why these 3rd party vendors for asp.net are there is just because of the fact that it is difficult to write UI controls for ASP.NET all by ourselves, and be able to target to all web browsers, and also that we are better off concentrating our time on the business logic rather than spending the whole lot of time writing the UI controls HTML code ourselves.
I understand that this feature gets us the full control over the final html, but is it not counter-productive to do this UI bit ourselves. If it was so easy to write them ourselves, how come these 3-rd party vendors are all living now. We could have done this all by ourselves all these years of WebForms days.
I am sure i am missing something here or being a little stupid, but please enlighten me as to what i am missing in specific regard to the UI bit being written by ourselves.
Just because i get full control over the program by writing in IL code, do we go and do that? We still use C# and things like that - So that theory of "having full control over html" - i am not bought into that idea.
Please help in getting my head around this UI bit.
Other things i understand, about the separation of concern, TDD based development possible with MVC etc.
But why would i go around writing the UI controls all by myself - it is a bit a work isn't it?
The thing is:
If you want to master in web development you have to master HTML + CSS + Javascript
And with WebForms you have to learn the WebForms way to do it, but with MVC you have the power of .Net with the freedom to generate the HTML + CSS + Javascript you want.
Here's a new rant on the subject http://www.charliedigital.com/PermaLink,guid,6dcb0333-9d70-40c7-975b-0ff4011c4661.aspx
Problem is, ASP.NET MVC is much younger product than ASP.NET. For many years 3rd party companies have been developing TONS of reusable components, and I believe that it is only a matter of time before comparable set of controls will be available for ASP.NET MVC.
If you really need very rich GUI with 3rd party controls, and you can't rewrite them in acceptable time - stick with asp.net. Altough in my opinion, MVC gives you tons of power it wouldn't be wise to spend much more time rewriting controls than you can save. If you can live without controls, and like MVC concepts - use MVC, and you'll most certainly see 3rd party solutions as soon as they'll there is growing market (maybe thay've already noticed that, I don't know) for mvc extensions.
I believe that the UI and the user experience are vital to the success of a web app. Making the page intuitive and easy to use, minimizing the amount of navigation the user has to do to get the job done, and providing effective feedback and interactivity can make all the difference between a site that users want to use and one that they avoid.
If you are trying to attract users on a public website, a pleasing appearance and excellent usability are key to building repeat visits.
If you are writing an intranet app to be used by hundreds or thousands of employees all day long -- as I mostly do -- making the UI efficient and easy to use really means a lot to your users.
So, I wouldn't downplay the importance of the UI. It isn't a nuisance. It's a key part of the user experience. I suggest that a web developer should embrace whatever tools and strategies that will get the job done. That often means coding the UI controls yourself. Or working with a teammate who likes doing that part of the work.
I recently refactored a very complex website using ASP.NET + handworked javascript to MVC + jQuery. The complexity of the code was reduced by 50%-75% and became much more testable. I replaced all the complex webcontrols I had to write (with a steep learning curve I had to overcome) with very simple HtmlHelper methods.
Don't forget, when you use custom webcontrols, you are given a very static UI by the control developer. With raw HTML, you can take advantage of styles and ui developed by the whole web industry.
Increased simplicity, decreased development time, testability, flexibility in UI... I don't want to go back.
You also have to remember that ASP.NET MVC is just the first release. I don't think there is intrinsically any reason why you couldn't have the equivalent of server controls to enable certain tasks - remember, there are many server controls that don't generate any mark-up (such as the Repeater, PlaceHolder, ListView). These type of controls could be useful in a future MVC setting, I think.
I believe that ASP.net came around when lots of developers were still used to doing desktop applications and just beginning web development. AT that point in time abstracting the details of the web with controls and post backs was a great way to get people started. At that point we weren't trying to perfect the web, we just wanted to get on it!
Now that the web has matured and we've all slowly learned about html, css, javascript and the likes we want to optimize our websites for our own needs and we don't want to depend on ASP.net Forms controls to control the fine details of our websites.
In summary, I think this is about the natural evolution of many developers from the desktop to the web
I for one, am very thankful that you cannot use ASP.NET controls in MVC.
Controls, as many have already pointed out, are just server side blocks of code that render HTML and javascript on your behalf. Things like a datagrid are great, until someone asks you to make a slight modification, like having a delete confirmation alert, and then it seems impossible to do certain tasks.
The good news is that there are very powerful jQuery tools written to help you. jQgrid is a great grid replacement that does WAY more than the ASP.NET grid...
http://www.trirand.com/blog/
jsTree is a treeview that is fantastic. Again with the jQuery....
http://www.jstree.com/
And the truth is that most things you can do with razor, HTML, javascript and CSS. It's so simple that it's just stupid.
It's hard for people like myself who were web forms developers to grasp MVC and why you should use it because it's so simple. It's difficult to let go of the complexity of conventional ASP.NET. But it feels so good when you do.
And don't mix web forms with MVC. You can do it, but you will wish you hadn't.
Here is the key thing that I think you are missing. When ASP.NET is no longer the MS way of doing things...you will eventually be forced to move on and do something else. I have programmed in perl, ASP classic, then ColdFusion, then PHP, then ASP.NET web forms, then ASP.NET MVC...the only thing that they all have in common is the underlying database, design patterns, best practices for a given set of technology AND...HTML, JavaScript, CSS, and Photoshop.
No one is asking you to learn MVC. No one is telling you to not use WebForms. However, complaining that you have to write a raw UI is not going to get you very far in this industry. You should be learning something new every day...and it sounds like some time spent on HTML and CSS would be a great place to start your focus!
The biggest problem you have with relying on third party controls is when a client asks you to do something that the third party controls don't cover. If you can't replicate their complexity plus the added feature request on your own you are skirting a possible failure in your professional livelihood! You will need to know how to do it all...eventually!
I generally suggest that you embrace new technologies. You don't have to use them...but you should at least know how. This way you will know what the best tool is for any given project.
I've been wondering - what's an equivalent of 'control' from webforms in asp.net mvc? It's not a partial view for sure. What else it can be? Controller + partial views via partial requests?
Maybe i'm dumb, blind or both, but i haven't seen any 'control' for asp.net mvc. Just a lot of code snippets to accomplish one specific thing or another.
I believe that asp.net mvc is quite unfriendly with rapid development. Only way out of this problem - a lot of open source code (like MvcContrib), tutorials, sample applications & most important - slightly smarter developers.
You do not have to replace Webforms controls with something else from MVC. Just mix them - http://www.hanselman.com/blog/PlugInHybridsASPNETWebFormsAndASPMVCAndASPNETDynamicDataSideBySide.aspx
Well, I was also wondering how to use 3rd party controls in ASP.NET MVC. Obviously, and contrary to some answers here, it had to be possible.
As much time has passed since the question was asked, the industry has evolved. So I've searched and found (but havent' yet tested) solutions such as Telerik Extensions for ASP.NET MVC .
I'm posting this answer here mainly to support other MVC newbees such as myself - Just Google
"asp.net mvc" controls