I'm currently working on a high-traffic online search site.
They have various changes they want to implement over time, and they've indicated that ultimately they want the site re-done in ASP.NET MVC.
Currently the site is an ASP.NET WebForms project; however true ASP.NET controls are rarely used. Instead there are lots of server-side tags - i.e. <% ... %>. The code in these tags will usually be a call to a static method in a static class or a fragment of C# code that generates HTML.
Many of the static methods generate HTML by appending text to a string-builder and returning it as a string.
I understand the concept of a 'Helper' method, but I don't like the idea of the HTML being rendered by concatenating it to a string variable. I think they'd be better off using 'Partials'.
The thing that concerns me is that it's a pretty complex site, and I'm not sure if a complete rebuild of the site in ASP.NET MVC is a good idea.
In spite of the bad structure, it's not really that hard to add the new features that are being requested. (Perhaps because I've had past experience working with difficult code).
However I think there's a risk that at some time in the future, a requirement will come along that will be very difficult to implement unless we do a complete clean-up of the code-base.
I want to put this question out there and see if anyone's faced a similar issue, and how you dealt with it.
Also what are your thoughts on doing the re-build as a 20%-time side-project? Are there any downsides to doing it this way?
Wow, this is some project.
Personally I think any site written in ASP.Net will need to be totally re-done as far as the UI is concerned. MVC does it a whole lot differently.
Your business logic on the other hand should be ok though me thinks so long as you have seperation of concerns and it's not bound to the UI.
Data access should be ok and probably needs minimal touching. But that again depends on how tightly bound your web site is.
I think the best approach is to spend some time looking at how MVC does business and do a critical analysis of what it would take to convert and then begin converting all the layers above the UI in preperation.
Get your foundation in place and maybe even, if possible, use the MVC framework already. Again, only if you can and only if viable.
Doing this as a side project would work I think because you can take some of your libraries and begin converting them in preperation for the mvc conversion.
But be mindful that once you have converted a project/layer that you (do) implement it else it runs the risk of being forgotten or changes get made to the other layer that then need to be coded into the new etc. You know the traps.
As for the UI, that's going to be the big one especially if you use a lot of asp controls. You maight want to spend a lot of time evaluating the UI and come up with a list of controls that you either need to replace or write. Then you can begin to see a pattern and get some consistency going.
If you have a lot of code in your code behind, you may want to begin moving this to another layer as this will help later on when you create controllers etc. They can then instantiate your new layer and all should be good.
That's all I can think of from the top of my head. I'll edit or comment as I think of things.
Hope this helps.
If I have that project and I was asked to redo it from scratch, I will not use MVC to render the UI, I will use Web API/OData to host all the backend, and will use any good Front End to draw the UI, Angular will be a very good option.
Having it as a side project is good only if the pace of changes and new features in the old project is less than the progrress done in the new project, you don't want to end up with doing duplicate effort and at some point you will have to code freeze the old one.
Also, you have to consider any data migration if you will have to change the data storage option.
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 have my existing web site developed using ASP.NET.
It's college management system. Now I need to redevelop it on MVC2.
What all changes do I need to do?
I am little bit aware of MVC and have done some exercises also.
Thing I know is I can keep my database intact but there will be massive changes at other places.
WHat will be the better way to minimize the changes?
MVC is a very different concept from event-oriented WebForms. There's good chance you will have to redo the frontend completely.
Try to find out if there is anything resembling data access layer and the business logic layer. If so, you can keep them (at least partially) and reuse their methods.
However, if the current application is not well structured and looks like a giant code blurb (with no layers, parts of the code talking to any other part at will, page methods going directly to the database etc.) it may have to be redone entirely.
If the application is now heavily relies on data-bound controls, you're screwed. You will have to recreate a lot of functionality by hand.
You should be able to refactor the middle tier (if you're using a multi-tier approach) into controller/model while keeping the UI intact. Once you've done that, throw away your UI and write a proper View. Try using LINQ-To-Sql for the backend.
I've taken over support of a legacy web app written predominantly in classic ASP. One page has a form for doing a job estimate, and consists of about 2500 lines of javascript and ASP code to achieve a "transparent edit" - i.e., the form is always in edit mode, and changes are instantly updated into the DOM.
There is also a "Print To Word Doc" button that, when clicked, goes to an entirely separate ASP file that produces (supposedly) the same view in HTML sent downloaded to a Word document.
The problem is that we have discovered inconsistencies and bugs in the two versions that are produced. My first response, applying the DRY principle, was This needs to be re-written in ASP.NET with a single code-behind file outputting the view for both the web page and the word document, so that we have one place to maintain the source.
However, upon getting into it, I'm questioning the wisdom of that approach, and I'm soliciting advice.
The problem is that, because of the integration of the view with the editing on the web page, as opposed to simply presentation on the work document, the two functions really do have two different purposes. Also, the ASP code, while ugly and hard to maintain, produces a reasonably nice-looking document. Doing the same thing in ASP.NET, at least using ASP.NET controls like FormView, is proving challenging. (One of the rewrite requirements is that the new page must function like the old page, minus bugs, of course.) The integration of the javascript to accomplish the editing functions on the client side makes for a good UX (assuming they work correctly). I can probably accomplish that same thing with AJAX and/or jQuery, but I'm wondering if I'm really gaining anything here.
How would you handle this?
You also have to take into consideration a couple of other issues:
How critical are the defects?
How
much time to do you have to get this
thing fixed?
How long will it take
you to correct the defects in classic
ASP?
How long will it take you to
convert the entire thing to ASP.NET?
At the end of the whole thing, will
anyone care which platform it's
implemented in? That is, will they
still be able to get their work done?
Because, at the end of the day,
that's all that really matters.
ASP.NET, while a wonderful thing, is not a silver bullet. If you're spinning your wheels, you're not being productive, and no one's getting a fixed product in a reasonable timeframe. It's like refactoring code just for the sake of refactoring it. It doesn't fix any defects, but darn does the code look pretty.
My advice to you: stick with classic ASP until you get the bugs out. THEN port it to ASP.NET. I'd much rather port a fixed product than a broken one.
That's a really complex question you're posing. The main issue is right there at the end:
I'm wondering if I'm really gaining
anything here.
Is the modification you need to make a small mod? or is it large? How much will you have to maintain this in the future?
You'll only realize dividends on your effort with future modifications. If you're never touching this system again, re-writing won't realize any benefits.
I have worked in projects in which we "converted" a classic ASP application into a .NET application. This is what we did:
Made a copy of the classic ASP files and then used the automated conversion feature from Visual Studio to convert this new copy into a .NET application.
Listed the .NET features we wanted to take advantage of in this new application and then found the correct places in the application to implement them.
Re-wrote code where needed to take full advantage of such features.
Refactored existing classic ASP code to avoid re-inventing the wheel where it was not needed.
Tested everything and then ran both applications in parallel until we felt comfortable that the new .NET application was running as expected.
I’m new to .net, though I’ve been writing in classic asp for years. I know it’s time to make the change, but I can’t stand how bloated the HTML becomes.
For example, a simple menu using a web.sitemap and adds over 100 lines of JavaScript and HTML. A simple form with server-side validation adds in masses of ugly JavaScript. And a basic table of data using GridView adds in a ViewState that makes my eyes water.
Call me a purest, though I don’t like sending data to the browser unless it’s needed. And I don’t need a form-riddled menu when a simple unordered list of links will suffice.
So, set in my ways, am I destined to forgo the benefits of the Framework entirely by insisting on writing my own, cleaner code for everything? Or am I missing the point?
As a brief aside I’m a big fan of Campaign Monitor, a newsletter distribution company. They’ve written an elegant and comprehensive user-interface in .net without a single ViewState or bizarre .net-mangeled ID reference. Even the Sign Up form on their website (/signup.aspx) is as clean as a whistle. What’s their secret?
I hope I not the only one. Any advice would be greatly appreciated.
Try ASP.NET MVC or one of the other MVC web frameworks for .NET
If your GridView doesn't need it, then turn ViewState off for it.
Also, please edit your question to say what version of .NET you're using. Some of this gets better, and some does not. You might also want to try VS2010 beta 1, and complain about anything it doesn't fix.
Another idea would be to go on treating ASP.NET like it's classic ASP. Do it exactly the way you're used to, but do it with the idea in mind that there's about 10 years of development work that's gone into solving some of the problems of classic ASP. Once you actually hit one of those problems, find out if ASP.NET has solved it, and how.
For instance, I have a hard time believing you enjoy writing FOR loops to generate table rows. If you get tired of that, learn to use a Repeater control, or a DataList control, or even the old DataGrid control. If you turn ViewState off on those, I think you may find the generated HTML to be acceptable, and you'll find it a lot easier to generate tables and other structures that repeat based on repeating data.
You can opt-out of much of that bloat by not using all the out-of-the-box controls that come with it but I prefer the MVC route that activa suggested
Here is my list:
Keep the use of asp controls to minimum
Turn off Viewstate when it's not need
If you don't want the JavaScript associated with Client Side Validation (with ASP.NET Validation) set the EnableClientScript to False
Use asp:literal instead of asp:Label
Yeah it seems to be that everyone is bashing webforms at the minute for the reasons you have outlined above. HTML heavy Controls, ViewState, no control over ClientIDs all seem to cause an issue with people.
However let is be said that you can use asp.net (webforms) and produce some decent applications.
Control of html is yours through httpModules and httpHandlers and some of the issues mentioned above are fixed in asp.net 4.0
I just listened to a great podcast comparing MVC and webforms. Its in the area you are asking about. Also check out this blogpost by a dotNetNuke regarding the good asp.net code and why people should take a breath before converting everything to mvc.
Having said that I've tried Asp.net MVC and it is awesome. I'd probably look at dotNetNukes code to as its a mature asp.net product.
Also, when you do want to use these newfangled server controls, check out the css friendly control adapters. They clean up much of the bloat.
For client IDs the key thing to remember is to let the framework handle them. If you need to get an element on the client side, remember to emit the control's ClientID property into your script.
I've been using a template system and am very happy with it. Basically write an http handler for .html files and put tokens in the html files that regex could find in one sweep and inject any stuff. (google template c# for more info).
I tried some of the supposedly cool new features of ASP.NET for a little while. I also didn't like most of them. I felt constrained to work within the limitations of the common paradigms Microsoft had dreamed, even though I new how easy it would be to produce the HTML and JavaScript myself to do specifically what I wanted to do without having to learn how to jump through the hoops of so many new Microsoft-specific idiosyncrasies.
Anyway, I stopped using the parts of ASP.NET I didn't like on new code I've been writing lately. When I first started using ASP.NET, nothing in the MSDN documentation jumped out at me about how to avoid such complications, so I posted a couple "Hello, World" at http://www.agalltyr.com/rawaspdotnet.html to help spread the heretical word. I couldn't care less if it's the latest cool technology or the recommended technique. It's a reliable and reasonably efficient tool I can use to do my work.
Oh, and I'm not in the mood to learn ASP.NET MVC either. That's just more idiosyncrasies. Give me a language (C#) and a framework (.NET), and I'll design my own abstraction, thank you.
Although ASP.NET MVC seems to have all the hype these days, WebForms are still quite pervasive. How do you keep your project sane? Let's collect some tips here.
I generally try to stay clear of it... but when i do use WebForms, i follow these precepts:
Keep the resulting HTML clean: Just because you're not hand-coding every <div> doesn't mean the generated code has to become an unreadable nightmare. Avoiding controls that produce ugly code can pay off in reduced debugging time later on, by making problems easier to see.
Minimize external dependencies: You're not being paid to debug other people's code. If you do choose to rely on 3rd-party components then get the source so you don't have to waste unusually large amounts of time fixing their bugs.
Avoid doing too much on one page: If you find yourself implementing complex "modes" for a given page, consider breaking it into multiple, single-mode pages, perhaps using master pages to factor out common aspects.
Avoid postback: This was always a terrible idea, and hasn't gotten any less terrible. The headaches you'll save by not using controls that depend on postback are a nice bonus.
Avoid VIEWSTATE: See comments for #4.
With large projects the best suggestion that I can give you is to follow a common design pattern that all your developers are well trained in and well aware of. If you're dealing with ASP.NET then the best two options for me are:
o Model View Presenter (though this is now Supervisor Controller and Passive View).
This is a solid model pushing seperation between your user interface and business model that all of your developers can follow without too much trouble. The resulting code is far more testable and maintainable. The problem is that it isn't enforced and you are required to write lots of supporting code to implement the model.
o ASP.NET MVC
The problem with this one is that it's in preview. I spoke with Tatham Oddie and be mentioned that it is very stable and usable. I like it, it enforces the seperation of concerns and does so with minimal extra code for the developer.
I think that whatever model you choose, the most important thing is to have a model and to ensure that all of your developers are able to stick to that model.
Create web user controls for anything that will be shown on more than one page that isn't a part of masterpage type content. Example: If your application displays product information on 10 pages, it's best to have a user control that is used on 10 pages rather than cut'n'pasting the display code 10 times.
Put as little business logic in the code behind as possible. The code behind should defer to your business layer to perform the work that isn't directly related to putting things on the page and sending data back and forth from the business layer.
Do not reinvent the wheel. A lot of sloppy codebehinds that I've seen are made up of code that is doing things that the framework already provides.
In general, avoid script blocks in the html.
Do not have one page do too many things. Something I have seen time and time again is a page that say has add and edit modes. That's fine. However if you have many sub modes to add and edit, you are better off having multiple pages for each sub mode with reuse through user controls. You really need to avoid going a bunch of nested IFs to determine what your user is trying to do and then showing the correct things depending on that. Things get out of control quickly if your page has many possible states.
Learn/Grok the page lifecycle and use it to your advantage. Many ugly codebehind pages that I've seen could be cleaner if the coder understood the page lifecycle better.
Start with Master Pages on day #1 - its a pain coming back to retrofit.
Following what Odd said, I am trying out a version of the MVP called Model Presentation which is working well for me so far. I am still getting an understanding of it and adapting it to my own use but it is refreshing from the code I used to write.
Check it out here: Presentation Model
Use version control and a folder structure to prevent too many files from all being in the same folder. There is nothing more painful than waiting for Windows Explorer to load something because there are 1,000+ files in a folder and it has to load all of them when the folder is opened. A convention on naming variables and methods is also good to have upfront if possible so that there isn't this mish-mash of code where different developers all put their unique touches and it painfully shows.
Using design patterns can be helpful in organizing code and having it scale nicely, e.g. a strategy pattern can lead to an easier time when one has to add a new type of product or device that has to be supported. Similar for using some adapter or facade patterns.
Lastly, know what standards your forms are going to uphold: Is it just for IE users or should any of IE, Firefox, or Safari easily load the form and look good?