I was given a project in WebForms to make robust and I had so far added several improvements to it. Don't get me wrong, I like WebForms for its simplicity but much of it is I feel like 'grandfather' type of coding.
Here's what I did, just to give you some ideas:
1.) Added VueJS to the frontend
2.) Added Webpack and a bit of ReactJS to on some pages
3.) Used .NET core on running a custom protocol app that triggers from inside the WebForms project
4.) I've added an emailing function (Inbox, Sent Items, Drafts, Trash, Junk, etc.) (from WebForms and jQuery, another one was WebForms + VueJS) to it as well.
It has gotten pretty big. I was just wondering if it will be scalable? Our management is thinking of putting it on the cloud soon but I believe it wouldn't work because of the architecture of our project - we will have to slowly transition it to modern web standards (apply MVC, use WebAPIs rather than WebMethods (static) on CodeBehind files).
I really am lost. What's the best route in improving a WebForms project to modern standards? Something scalable and cloudable (if that even is a word).
Thanks.
(Let me reach for my flame-retardant underwear.)
The big difference between WebForms and more contemporary web design frameworks is that WebForms attempts to layer an event-driven forms management paradigm on a platform that is not built for events. Web pages are not desktops.
In my experience, the efforts to maintain the illusion of web events in a complex application far outweigh the investment in taking the original functional requirements to MVC, or NodeJS, or React, or some framework that is designed for the calls and responses of the stateless servers of the Web.
I vote do-over. You will have to do your own cost/benefit analysis if you want to take that route. If you do go that way, this forum is a good place to post specific questions with code samples related to coding problems that you uncover on your journey.
Related
With the latest release of ASP.NET CORE version 2.0 we now have Razor Pages which I really like because it shows a MVVM way of developing which I am already familiar because I've used it in UWP.
I was searching to develop web apps without js because I am a .net developer and I came across this framework known as DOTVVM , it is great because it gives some features of js frameworks like Angular, React etc. and it also integrates very well with ASP.NET CORE 2.0
I want to discuss this between following 3 scenarios :
I should use DOTVVM and not use JS at all.
I should use Razor pages instead with asp.net core 2.0, because razor pages provide all functionality which dotvvm provides and it will have more community in future.
I should learn a JS framework like Angular or React because neither razor pages, nor dotvvm is powerful enough to replace them.
The discussion can be from point of view of all developers, so I can get opinion of JS developers as well as those who have worked with dotvvm or Razor pages. The aim is to create completely interactive and responsive web app with good performance.
**Important : ** the web app created can be a progressive web app from the start or maybe turned into a pwa after creating it, depends on the technology I choose at the end.
I know for a progressive web app I will need to write a little JS, but that is alright considering that is very simple and little to write.
The reason of this question is so that we can discuss these options from multiple perspectives and deduce a better option at the end for my app.
It really depends on the type of the application you are trying to create. The fact is that you can build any application in any web technology. The difference is only in how difficult it would be.
Razor Pages are very easy to use and they are part of ASP.NET Core platform. They are using the MVVM pattern, but they are not helping with client interactivity. If you need to hide some form field based on some condition, you would need to do it in JavaScript.
I would use them for a simple company website, very simple admin sites with few pages and trivial forms, or for a public facing part of some eCommerce site. I would probably use also jQuery or other libraries to do the interactivity, animations and things like that.
DotVVM is an MVVM framework which helps especially with web applications with complicated UI: lots of complex forms with dozens of fields and interactivity (when you select an item in a combobox, another combobox will get new values, some fields will be pre-filled, a part of the form will disappear or change and so on). Modal dialogs, multi-step wizards, lots of grids with data, sorting, paging...
Because DotVVM handles many things for you and translates the data-bindings to JavaScript, you don't need to write the JS yourself. It doesn't mean that you should not learn it. It will help you a lot if you know it - you will be able to add even more interactivity, extend the framework when you need it and more. DotVVM lets you do quite a lot without knowing JS, but you will get much further if you know it.
Angular, React or other client-side frameworks are used widely today and many websites and applications are built in that. They are more universal than DotVVM, which aims primarily at the business app segment and requires .NET on the server (because it is not only the client-side library).
Using Angular or React requires the knowledge of JavaScript, and not only that. You will need to know Node.js and the related tooling, like npm. You will need to exchange data with the server, so you will need to build probably a REST API, use Swagger to generate the client-side proxy classes, and then you will probably need some other JS libraries with controls and things like that.
It is quite a lot of things to learn and if you are used to the comfort of Visual Studio, like the IntelliSense or the debugger, you will miss these features for sure.
And finally, you don't need to stick to one technology. You can combine Razor Pages with DotVVM for example. You can make the admin dashboard in DotVVM and the public part of the website in Razor Pages.
Microsoft is coming back to the WebForms approach to simplify the project structure trusting in the "Convention over configuration" mantra, while hiding the configuration from developer to make things faster. But it has the disavantage that everything will be mixed again. I doesn't look like a smart move for organizing. But... Hey! Something new must catch the attention of the dev towards Microsoft.
If your page uses an MVC Web API for the REStful, it's really more easy to just use Razor pages. If not, I would recommend you to use Core MVC.
Is it possible to self-host an ASP.NET MVC application and/or OData service in a stand-alone workstation app? Are there any successful examples of doing this?
I would like to create a suite of data-centric applications using .NET that are targeted to EITHER a solo/home user OR a team. Unfortunately, I am the only developer. Comparing front-end technologies of WinForms, WPF, and ASP.NET MVC, I am most proficient with ASP.NET MVC. I would also not like to write multiple implementations of my data service.
(Commenting in lieu of voting down as my profile cannot yet vote down.)
You really need to do some research here. Almost any service-oriented .NET technology can be self-hosted... WCF web services, OData, etc. Your bigger concern should be performance. The more layers you add to your app, and the more times you transform or "serve" your data, the more cycles will be spent processing your data. What you may find is that you users become less happy with the performance compared to a snappy compiled UI hitting a simple business or data layer.
In short, yes, this is possible. However, I would save this type of app for one-off / in-a-pinch apps with either a short life expectancy or very minimal client usage (settings panel, etc.).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Diamonds is an ERP based on windows forms, I'm going to redevelop it using web technologies rather than Windows Forms ..
but now I need to decide which is best for this, the ASP.NET webforms (as i think) is easier to (design) i mean here the UI, but the mvc has simpler html output, and some other features ...
can you help me decide which technology to use and why ?
I'm using C#,
Cheers
If you care about extensibility, ease of maintenance, scalability and robustness of your application, as well as development of your software development skills, then stay as far away as possible from web forms.
The whole idea of adding a layer of state by wrapping everything in a form is just wrong. HTTP is stateless, and MVC is built around that model, which is good.
Edit
In regards to the comments made. Web forms applications are not extensible because presentation layer, business logic and data access code (data sources) all reside in code behind. Controls that are offered by web forms are applicable only in web forms. This means that you won't be able to transfer these skills to another web development framework.
Finally, of course it is possible to write a tightly coupled application using MVC - there is always a way to destroy something. There is no argument about that. The main point is that MVC encourages a seperation of concerns and single responsibility principle, when web forms practically takes it away from you.
You have also said that web forms is easier. It's easier if you have been using it and it's faster to pick up in comparison to MVC, however, in a long-term run MVC is likely to become "easier". Watch few videos on www.asp.net/mvc. Additionally you might want to look into test-driven development (unit-testing). I don't think that unit testing works with web forms because everything is so tightly coupled. Please correct me if i'm wrong.
I would be very interested to hear opinions of other developers who have experience of working with both frameworks.
I think both technologies can get a bit complicated after getting past any of the basics. Here are some brief opinions that I gathered while having to implement a project that must live in both MVC and WebForms hosts.
WebForms Positives:
The maturity of the product
Lots of 3rd party support with regard to sophisticated controls
There are ways to get around the legacy-feeling aspects of the framework (e.g., WebForms MVP)
WebForms Negatives:
Page lifecycle issues can anger you to no end; there are a lot of moving parts to a sophisticated web application
Using dependency injection is "difficult" to use/implement
There is a lot in the framework that you can't control
Need something like Reflector to dive into decompiled source when have questions that are not answered by documentation, web, experimentation.
MVC Positives:
Great separation of concerns and support of dependency injection
More control over so many things (i.e., project structure, mvc framework, rendered content, etc)
You can xcopy deploy your app along with the mvc framework on top of an asp.net 4 installation (i.e., to a 3rd party hosting provider)
Native support of JSON
Source code (w/ comments!!) provided so that you can dive into various features when you run into questions on the internals.
They've been doing out-of-band releases on tooling and I believe plan to do so on the framework (?); they have a futures project along with the source that shows you some of the directions they are going and which you could make use of if you should choose to.
MVC Negatives:
Can take a little time to wrap one's mind around
Not as many 3rd party helpers (no controls); those that exist seem to be not as sophisticated as their WebForm counterparts
Personally, I'm an MVC fan because of the control, flexibility, and transparent dependency injection support. Perhaps you should do a small pilot with both technologies to see which one you prefer. Good luck and have fun!
I strongly recommend MVC simply because once the UI is ironed out, it makes development so much easier from a back-end viewpoint. There are TONS of mvc vs asp questions out there:
1,
2,
3
From my perspective MVC wins based solely on TDD and no Viewstate. But it really depends on how you plan to manage and use the various features of either.
I think this post from Scott Guthrie is really interesting to read. After reading, I think you'll most likely go for ASP.NET MVC. :-)
While I have done plenty of projects with web forms, I have to say that the primary reason they exist is to provide a layer of abstraction over HTTP, largely to facilitate an event-based model on a stateless protocol. Unfortunately, like most MS solutions, that comes at a price.
Historically, web forms used to be plagued with issues around the generation of markup. Some of these issues still persist today, especially when it comes to ViewState. Things are slightly better now( you can manage the DOM id in ASP .NET 4.0 ) but web forms will still cause you grief. Common things you'll see in web form projects are vast amounts of biz logic squirreled away in codebehind.
MVC doesn't eliminate this, but it provides a structure and separation of concerns that makes bad practice less likely. That said, although the default view engine is better at producing clean markup from an end-user perspective, the inline code in views is a throwback to classic ASP.
For what it's worth, I've stopped developing web form projects and have moved exclusively to MVC for new work.
IMHO MVC
I had to write a report to justify changing to MVC from Web Forms/Nettiers
I blogged my arguments here
It's all about your choice having Web Forms can give you easy of designing your app where as MVC is now days becoming industry standard and even MS is promoting it a lot. If you want to keep your code clean then no doubt MVC is better choice.
We have a ten-year-old ASP application that we are considering planning an update for. We want to take advantage of the new technologies that ASP.NET has to offer, as well as the opportunity to fix some issues with the existing framework (the existing code-base is highly fragmented, nearly impossible to test, let alone debug, and the entire application appears to have been constructed according to the "Farmhouse Pattern".)
To that end, it seems that the time has come to rebuild this application. But, we are a small business, and we simply don't have the resources to either hire out the rebuild, nor to dedicate our small team of developers solely to the task of rebuilding (we've got other tasks on our plate, and can't concentrate on this one particular task for the length of time it would take to fully reconstruct the application).
What, then, are some useful strategies we can employ to help us convert this app, without having it consume all of our limited resources for the duration of the re-write?
Sounds like an interesting challenge. It's definitely not going to be easy, especially if you can't dedicate any resources to the project full time.
If you have a 10 year old application that is working, I would suggest not going for a complete re-write at all. I would start by sitting down and figuring out what you want your end product to be.
Is it going to be an ASP.NET MVC Web Application, an ASP.NET WebForms App, or something else? Once that decision is made, come up with a loose design for an architecture. If you do things correctly, you can build out bits and pieces of the business logic in .NET and utilize it from your Classic ASP code until you're ready to re-write the UI in .NET as well.
I agree with what Justin said; if you have a working application in place, you'll need a compelling reason (i.e., money) to justify the expense in rewriting the application for a new platform.
Although ASP classic and ASP.NET share a similar-looking syntax and some common coding conventions, they are very very different from each other. If you tried to simply copy-paste classic ASP code into an ASP.NET application, you might be able to get it to work, but you'd be missing out of a lot of the advantages of ASP.NET Web Forms or ASP.NET MVC (and their respective frameworks, of course).
You can, however, extend the functionality of the existing site with .NET code through web services or COM interop. We have a 10+ year old classic ASP web site and I've used both .NET web services (.asmx) and COM-callable .NET DLLs to enhance our existing application. In both cases, I wrote all of my new business logic in the .NET component and provided a chunky interface to work with the existing ASP page. That allowed my .NET code to be very easily testable and still use our existing (huge) investment in our classic ASP site.
The only approach that has worked for me is to carve of areas of functionality in small slices, and rewrite. "Converting" first, then refactoring seemed like a good idea a few times, but in the end just became horrible messes of code written in ASP.NET instead of ASP - and that added no value.
If you have a site that has distinct areas of functionality, carve one off and start with that (I chose "contact us"). Write it the way you think it should be written - that is, assume your new part is fitting into the end design of your well-written app. If you have to add "hacks" to interface with the old system, make sure they are isolated and commented.
When working on an update, think "can I carve of some of the functionality here into it's own bit?" - if so, convert it then update it. I found that if you insist on keeping the NEW app clean and allow yourself to add small hacks to the OLD app for communication, you get the best results.
This does mean you'll have two separate apps (two IIS web apps) for a while, and can make cookie/url and session management a bit hairy, as well as adding one more deployment concern. To combat this, make sure that you minimize state in your web app (always a good idea anyway), and share state through something other than Session.
If you do this a piece at a time, make the pieces small enough, and have a good design up-front, this works well - at least in my experience, it's the way that works best. Note that my experience may not match reality.
I'm developing a website , job portal. I have 2-3 years of ASP.NET webform development experience,
I want to create a professional job portal site (to improve and learn more) but trying to decide on best architecture. Any suggestions or advice will help...
Thanks
Well, there are a number of ways to answer this question, and I'm sure many others will chime in. I'll just say that since your goal is to improve and learn more, and you already have 2-3 years of webform experience, this might be a good opportunity for you to learn MVC. Then you will have experience in both, and can make more informed decisions regarding the best architecture for future projects.
Happy learning!
Whilst nobody can tell you exactly what to do, the team I manage is about to release a new CMS / Job portal using ASP MVC. MVC gives us excellent testability and scalability out of the box and it can be quickly combined with tools such as nHibernate / windsor (IOC) / nCache / jQuery - this ensures that you have a wealth of resources on the internet to help accelerate your development and skill. You can also embrace standards such as XHTML 1.1 strict, which is almost impossible with ASP.Net webforms due to the auto generated HTML
1 other advantage is that you also get away from the dreaded ASP.Net viewstate.
Use ASP.NET MVC if you want to:
learn the ASP.NET MVC framework
use jQuery or similar libraries
really learn web-languages (HTML, CSS, JavaScript)
use Test Driven Development
have a clean separation of concerns
If you don't have the time or will to learn to use the ASP.NET MVC framework correctly, stick with ASP.NET WebForms.
My answer is almost always "ASP.NET MVC." The amount of flexibility and features and testability and maintainabilty and ... heavily outweigh WebForms.
WebForms has the advantages of a rich ecosystem of existing controls and documentation, and is really powerful for some kinds of tasks (complex, multi-form interactions), but I find its limitations get in the way far too often. You have to mold yourself to it.
It really depends on what the end goal of the application is. As Scott Ewers said, if your goal is to learn, then using ASP.NET MVC will expand your breadth of knowledge in the ASP.NET space (since you already know web forms).
Additionally, if this is going to be a public product, you can leverage the testability benefits of MVC and run automated unit tests. Key ideas like Separation of Concerns can also increase long-term scalability and maintainability.
The primary reason why you might choose web forms is if you are rapidly prototyping the job board application. As you know, web forms allows you to drag-and-drop components onto the canvas to quickly create some basic data entry functionality.
There is a herding code podcast from May 13 on the subject.
Herding Code 47: Joe Brinkman on Webforms vs ASP.NET MVC.
I also agree that choosing MVC would have the advantage of allowing you to expand your knowledge. That not being the only reason, given the choice as well I just finished a small MVC project (my first) and let me tell you MVC rocks! Its a great framework which I feel gives you more flexibility and at the same time out-of-the-box tools to create a web app quickly and painlessly. It was my first experience with VS2008 & .NET FW 3.5 & LINQ, and all the guides at www.asp.net helped me go forward quickly (especially the free tutorial chapter from an MVC 1.0 book mentioned here).
I also got to learn JQuery along the way, as it is very much integrated into these new technologies.
One think to take note though is that this being a new tech, version 2 is already being cooked up, so if your project is for the long run, have that in mind and plan accordingly (in my case, being a small project, I'll probably try upgrading my project to version 2 when its officially released). Yet at the same time, having a fully MS (and thus MSDN) supported version 1 was a godsend for me...
Good luck!
I have good experience in Jquery, CSS, HTML, Javascript but not in TDD.
I have time..and willing to learn MVC but wasn't sure MVC is good choice for Job portal or similar site..
This can be considered a shameless self-advertisement but here is my quiz on how to choose between the two:
http://sietch.net/ViewNewsItem.aspx?NewsItemID=101
I was recently tasked by one of my clients to write a paper, or simply a checklist, that would help other lead developers make this same decision.
I posted the first 2 rough drafts on my blog. I am admittedly pro-mvc but the paper/checklist has been we received so it might be helpful.
http://eric.polerecky.com/archives/a-somewhat-less-biases-comparison-of-mvp-and-mvc/[http://eric.polerecky.com/archives/a-somewhat-less-biases-comparison-of-mvp-and-mvc/][1]
I think the most often overlooked benefit of MVC is convention; I really see any convention in webforms projects and while not strictly enforced in MVC projects at least its there.
i started developing our current app in webforms, mvc wasn't available when development started.. i've chosen the MVP pattern, with URL rewrite HTTP module. currently i'm investigating plugging in some MVC into this, basically to use the front-controller instead of using page-controllers. the other things in already established MVP architecture with web forms in my app give me more flexibility than pure MVC approach without WebForms, which i like, although require a bit more code than MS MVC examples (never tried it for real project to see if it stays that way, like in those examples in screencasts).
what i don't like with MVC is mixing control code inside templates - i believe loops, ifs and stuff like that just shouldn't belong inside the template. but a couple days ago i've ran into Spark view engine that looks kind of promising in that segment, although not still close to the Tapestry 5 (a component-based webGUI framework) in the java world.
But the above mention suggestion to mix both might work for you to explore MVC world and have the safe ground to fallback to if something won't work for you might be ok for you.