|
I agree 100%
Guess in hindsight, my gripe with WebForms was just related to me wanting to do more with UI and JavaScript and create more fluid interfaces. My target audience at the time was low skilled construction workers still running Windows XP and Corp buyers using the latest in tech. I wasn't able to make the UI easier to use in Checkout. Plus I designed a really bad data model for Checkout as well. The checkout process killed me.
I really feel that the concept of MVC has solved alot of the previous issues I had with WebForms. Whether the MVC is MVC, or Angular, Drupal, or something in PHP, I just like MVC better.
But to reiterate again, it's a shame that WebForms has sort of locked coders into a box, a certain way of thinking that seems to block new exploration into the parts that make up WebForms, to basically create HTML and use the HTTP protocol in general. Or to move forward to disassemble WebForms into it's actual components, and put it back together again as something better with other components.
If it ain't broke don't fix it
Discover my world at jkirkerx.com
|
|
|
|
|
We've all been there with "demos"! Guaranteed way to highlight any bugs in your systems. 
Re ViewState - the author of that snippet seems confused anyway as client-side viewstate does not involve "a large encrypted file ... client-side". Client-side view state is simply Base64-encoded data held in a hidden input field. (It can, optionally, also be encrypted). But in any case, arguments such as "the developer doesn't know how much space is taken" are erroneous; it's up to the developer to specify how much is being taken, because s/he should be actively coding, not just accepting defaults for everything. It's the developer's choice whether something is included in ViewState or not. If the developer doesn't have a pretty good understanding of what's in viewstate and why, then just bunging it all server side is not the answer!
|
|
|
|
|
I think F-ES Sitecore has covered a lot in his comments. I do understand what you're saying about Webforms sort of "hijacking" your HTML and can see that could have impacts in all sorts of areas. I came to ASP.Net from a Classic ASP background where I was very familiar with HTML, CSS et al and initially found ASP.Net confusing. It wraps certain input elements in spans etc which can play havoc with styling. I can imagine it would be doubly baffling if you use the visual designer. I work 100% in code and (once I'd twigged about the wrapping of radio buttons in spans) haven't really come across issues with its HTML generation.
As for AJAX - I was building single-page applications years before anyone coined the term Ajax, so tend to either roll my own Ajax from scratch or, for simple use-cases, use JQuery's features. Dead simple, and no extraneous Javascript files inserted for you by ASP.Net - no need for ScriptMangler or any stuff like that.
ViewState can be a massive issue, but only if you leave it at default settings. You have a lot of control over what goes in viewstate and if it's not needed, don't put it in there. I've seen sites with viewstates extending to megabytes of data that only needed a couple of hundred, if that. And as F-ES Sitecore says, that's nothing to do with sessions. And of course, you can have multiple forms on a page. (E.g. I often have a login / reset password form, a search form, and a "main" form on just about every page).
Performance will be poor if you have a poorly designed application that doesn't make proper use of things like postbacks, viewstate, scripting etc. But that's true of any language / framework. I've found that when I take an old app I've written and re-write it, it performs better - regardless of the original and rewrite languages. That's not a language or framework issue, that's me having learnt "stuff" and building a better solution.
I guess in practice I only use the bits of Webforms that make my life easier or make the application more useable / reliable. I do roll a lot of my own code and make it very situation-specific, so it's lightweight and doesn't try to be all things to all people. That said, I've built up a library of techniques that I re-use time and again, and that makes development very fast in Webforms.
Really appreciate your input and comments; always interesting to get someone else's perspective on these things!
(PS Still waiting for your site to load  )
|
|
|
|
|
If you like AJAX then you will find it easier in MVC. WebForms wasn't designed for ajax, it was designed to be stateful across post-backs whereas ajax is stateful without the postback. While it is possible to use ajax with your webforms, it's just easier with MVC. The "template" nature of the razor views means you can use the same view and data to render html on page load that you can use to render html for an ajax call. The way MVC interprets urls using routing and data-bind also make ajax calls easier.
The other advantage is that it gives you better control over the html, which can also be a negative as it can take slightly more effort. Finally if you're into unit testing the fact that MVC "code behind" has greater layer separation it is far easier to implement unit testing at the controller and model level as there is no inherent dependence on the http layer.
|
|
|
|
|
"What's so bad about webforms?" Nothing, I say. The only thing you may want bear in mind is future maintainability by your project successors, if that is an issue. For whatever reasosn, WebForms are going out of favour, and finding (good) developers in years to come who can work with WebForms will only get harder.
But in and of themselves, WebForms are just fine. I still use them when I can get away with it. And I certainly don't have the issues with them that @jkirkerx does. (Who uses labels anyway? Use a Literal if you need to inject some HTML.) Quote: As a negative effect, you never really master HTML or HTML5.
I gave up learning HTML/CSS years ago anyway - that's what front-end developers are for! It's their job to make sure thinsg render on different devices. I just use what they give me. I never use the designer features in Visual Studio. Quote: I also got burned by the Ajax Control Toolkit.
I've never used the ACT. AJAX is simple enough to use with vanilla JS, or jQuery if you're using that anyway. I avoid "black-boxes" whenever possible. I like vanilla, and the KISS principle.
The trouble with so many out-of-the-box solutions to things is that they need to be all things to all people, catering for all scenarios. If you actaully sit an think about just what you need, it's usually only a tiny fraction of what some magic box offers, and you can have leaner code, with the added benefit of learning more, by writing your own code that does just and only what you want.
Nor have I expereienced any problems with Google, or IIS.
I'll have to take jkirkerx' word for it when he says "Now I can develop in 1/16 the amount of time it took me in WinForms" (I presume he means WebForms) but I can't say I've found that much difference, if indeed, any.
I like WebForms. I do accept that MVC, and now .NET Core, haven't come about for no reason, but there is a "horses for courses" aspect to all this. If you're a single developer on a relatively small-scale project (small business / charity / school, maybe) not too concerned about your code in 20 years... then there is no reason to give them up, if you're happy with it.
(On a separate but related note, I could make similar arguments for that other "black sheep" of the coding family: Visual Basic. Of course there are things you wouldn't use it for, but - horses for courses again - for smaller, simpler projects, why not? It's easy, quick, and quite up to the task - it does, after all, leverage the same .NET libraries under the hood.)
|
|
|
|
|
Thanks for your thoughts, A_Griffin. Seems you're a developer after my own heart! i.e. use the bits that work well for you, but don't over-engineer stuff and roll your own where it's a more effective / maintainable / robust solution.
Sadly I do also agree with you that finding skilled webforms developers is getting harder and harder (am currently looking for someone to take on support of a webforms application). Not only are new developers not learning it, but those that know it are increasingly reluctant to use it as, presumably, it detracts from building their MVC experience.
Finally I also agree about VB.Net. It's using the same framework as C# and, in the great majority of cases, provides the same functionality via a different syntax. I went through the process of converting a non-trivial VB.Net application to C# and an automated converter was able to do 99% of the changes for me, which suggests to me that the two languages are virtually equivalent. Sure, C# may encourage certain good coding habits, but a badly-written C# program is always going to be worse than a well-written VB one.
|
|
|
|
|
Derek...
Your arguments regarding WebForms are quite sound and I have written papers on the matter over the years.
As one commenter posted, the WebForms design was to make its development similar to WinForms, which at the time was where most Microsoft developers would have been moving from, or form Classic ASP, which was more difficult to provide necessary functionality.
There is absolutely no business advantage to the use of MVC over WebForms. In response to the commenter who has found MVC far superior to develop with I can only assume he has never worked on a massively, complex, MVC project as I did back in 2010 using MVC 2.0 (it was one of the largest MVC projects in the US at the time).
Such projects place one in a position to see all the failings or rather the impediments of using the MVC paradigm, which is the massive, additional detail that WebForms helped to reduce.
For all the complaints regarding WebForms, I can list just as many for MVC. However, one can design well functioning MVC applications just as one can do the same with WebForms. It is all how it is done.
Despite this, MVC will take a much larger learning curve to master well and the supposed desire or preference for more control over the development of components to an MVC application is more or less merely a mirage that MVC proponents like to tout. Just like the comments that one can develop faster with MVC than in WebForms. If one is finding this in their daily development endeavors then they are not doing anything dramatically complex.
However, the underlying reason for the move from WebForms to MVC was basically a result of a "herd mentality". Everyone was doing it so most felt they had to get on the band wagon.
At the time this move began, which was around 2010 or so, there was growing influx of younger technicians mixed with a strengthening in the Open Source Movement, which combined to push the greater complexity of MVC over the more simplistic WebForms paradigm whereby such complexity had been early drawback to the Open Source Movement itself. The other elixir in this mix was the rapid growth of stupid-devices that everyone believed (and still do) was the Second Coming in technology.
To be sure, WebForms did have its drawbacks technically. However, Microsoft continued to refine it over the next several years, where it could easily match the capabilities of MVC where WebForms had originally been weakest. However, by then, the damage to the WebForms environment had already been done by the technical community itself.
If you do the in depth research as I have done regarding the many reasons for moving from WebForms to MVC you will not find a single, solid technical reason for doing so except for the fact that it is what one does now. Business users really don't care about any of the reasons that technicians give about the superiority of MVC. All they care about6 is if the applications they have to use work well.
Though I retired several years ago, I still do development. However, when considering expanding a current commercial product into a larger format that could be used by small companies instead of just by individuals, it didn't take me much time to make the decision to stay away from web development and simply go in the direction of a client-server model.
Because of the MVC paradigm, web development is now a complete and utter mess. This is not just a result of MVC's additional complexity but the reliance on multiple frameworks based on JavaScript, a language that has never been modified to be used in the way it is being used now. It is still the rickety critter it always has been but with a lot more lousy documentation. This secondary outgrowth was primarily perpetrated by a Me-Too Movement in the technical community whereby everyone now believes they can produce commercial level quality using low quality concepts and tools (ie: JavaScript).
I can make this claim just by observing the continuing and increasing data breaches against corporations (who still continue to pay lip service to security while using insecure techniques to develop their applications) and the increasingly poor quality of many public facing web sites.
It doesn't take a rocket scientist to see that web development has been going downhill since 2010 and even professional technicians have weighed in on this trend here on The Code Project itself...
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
Steve, many thanks for the insights you give from someone who's worked on non-trivial applications in both technologies. Your comments confirm what I'd suspected. I work with lots of smaller clients - in most cases completely non-technical - and though I make it clear in my proposals I'll be using WebForms technology, this has never been an issue and the customers are happy with the end result.
One area I might slightly disagree is in your comments about Javascript. The reality is that if you need to create a website-based solution that loads without requiring additional support software on the client machine, there's not a lot of options if you need a functionally rich application. Despite all the many detractors from Javascript itself on this site and elsewhere, the biggest problem I've encountered is the scores of bolt-on "frameworks" each claiming to fill in the gaps in "easy" functionality from raw Javascript. A lot of these are bloated, inefficient, bug-ridden, and poorly documented. Even a good developer can struggle to build a decent site using (where I agree with you) low quality tools. Sadly there are too many "developers" who are not good, and the good ones get tainted with the perception that web developers can't deliver a decent product.
My feeling is that the rush of new frameworks and languages has slowed down a little in the past couple of years. Some technologies are beginning to mature and recognition is spreading that the way we approached development a few years ago (just grab components off the freeware shelf, together with whatever framework dependencies they dragged with them, and throw it all together) won't cut the mustard.
|
|
|
|
|
DerekT...
I should be thanking you for your reply...
You are part of a growing chorus of professional technicians who are starting to realize that increased complexity does not always translate into increased capabilities or even ease-of-use.
Most of the original complaints regarding WebForms were legitimate. However, they were primarily targeted at the internals of the environment, which in many cases had work-arounds so one could avoid their pitfalls. However, as I had mentioned, Microsoft worked to improve these internals and did a rather good job of it.
Had the community not simply walked away from the WebForms environment, it would have received more refinements.
Of course we have the Microsoft issue where the company continuously "throws the baby out with the bathwater" when introducing new refinements and\or products. This corporate problem did not help their case to maintain WebForms as a viable development environment.
As to JavaScript, I understand your disagreement with my position. However, I was not referring to the necessities of using the language for hosting capabilities at the web client but instead its general use as a major development language through the use of all these cryptic frameworks.
Doing so has changed the orientation from server-side supported applications back the "fat client" model, which is the very thing that was fought against in the late 1990s and early to mid 2000s. Professionals that time all agreed that the "fat client" model was unwieldy and presented more issues than it was worth. Thus, we stuck with the "thin client" model, which I still adhere to.
When MVC emerged, many professionals used it as an excuse to blame the inefficiencies of WebForms as an environment that was not workable while laying the blame on its internal model (web-page\code-behind) as the basis for many poorly written applications. However, this aspect of WebForms was never the fault of the design but the result of poor development techniques. The Code-Behind component side of things was only intended to be a dispatcher while also handling immediate display constructs. Nonetheless, many developers merely stuck a whole lot of code in these server-side modules making WebForms look more like a whale than it actually was.
MVC brought JavaScript into forefront as a major development language for which it was never intended and it has been responsible in large part for the mess that current web development has found itself in.
Despite all of the crowing regarding MVC, I have never found a single analysis of the performance aspects of it against WebForms with the exception of a single professional's curiosity who bench-marked an in-house application in both environments. He found that after 100 concurrent users in either application there was absolutely no difference in performance between the WebForms and MVC applications.
To me, WebForms was and still is the zenith of web development on the current Internet topologies. Considering that the Internet was never designed to support what is being thrown over it today, WebForms was a very successful implementation to make such development a far easier and more approachable technology when compared to anything MVC has to offer.
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
Error:'D:\test_data\sample_bulk_upload_File.xls' is not a valid path. Make sure that the path name is spelled correctly and that you are connected to the server on which the file resides
code::
path = TextBox3.Text
s1 = "Provider=Microsoft.Jet.OLEDB.4.0;" & "Data Source=" + path + ";Extended Properties=""Excel 8.0;HDR=YES;"""
Dim OLEcon As OleDb.OleDbConnection = New OleDb.OleDbConnection(s1)
Dim OLEcmd As New OleDb.OleDbCommand
Dim OLEda As New OleDb.OleDbDataAdapter
Dim OLEdt As New DataTable
Dim sql As String
Dim resul As Boolean
OLEcon.Close()
Try
OLEcon.Open()
With OLEcmd
.Connection = OLEcon
.CommandText = "Select * from [data1$]"
End With
OLEda.SelectCommand = OLEcmd
OLEda.Fill(OLEdt)
For Each r As DataRow In OLEdt.Rows
|
|
|
|
|
The path D:\test_data\sample_bulk_upload_File.xls is valid on your development machine, and becomes invalid once deployed to the production server. You need to provide a path which is valid in the context of executing environment.
The best solution for this kind of issue is to avoid hard-coding the path. Better include it in a configuration file, of which you can have separate versions for development and production environments.
"Five fruits and vegetables a day? What a joke!
Personally, after the third watermelon, I'm full."
|
|
|
|
|
Hi Phil,
Thank you for your comments, I have already tried the file upload tool to perform this but that was not working , hence I am using static path or physical path.
Do you have any example for this type of issue?
With Regards
Rama
|
|
|
|
|
|
I have a datatable like this
----------------------------
STID NAME DOB SBCD
----------------------------
1001 XXX DMY AAAA
1001 XXX DMY BBBB
1001 XXX DMY CCCC
1001 XXX DMY DDDD
1002 YYY DMY AAAA
1002 YYY DMY BBBB
1002 YYY DMY CCCC
1003 ZZZ DMY AAAA
1003 ZZZ DMY BBBB
1003 ZZZ DMY CCCC
1003 ZZZ DMY DDDD
1003 ZZZ DMY EEEE
I want to convert this datatable into following format and bind it to gridview.
----------------------------------------------------------------------
| STID | NAME / DOB | SUBJECTS |
|------|----------------|--------------------------------------------|
|1001 | XXX | AAAA BBBB CCCC DDDD |
| | DMY | |
|------|----------------|--------------------------------------------|
|1002 | YYY | AAAA BBBB CCCC |
| | DMY | |
|------|----------------|--------------------------------------------|
|1003 | ZZZ | AAAA BBBB CCCC DDDD EEEE |
| | DOB | |
|------|----------------|--------------------------------------------|
|
|
|
|
|
Hi Friends,
I have web application along with few Class Library Projects.
I need help in implementing the following 2 points.
i) I have method written in Master Page code behind, I need to access this method from all my content pages.
ii) I need to access Master Page (like this.Master) from my another Code library project in the same Solution.
Kindly suggest on the solution.
Thanks in Advance,
Regards,
Priya.
|
|
|
|
|
If you use the MasterType directive it will let you use strongly-typed master pages. If your master page is;
using System.Web.UI;
namespace WebApplication1
{
public partial class SiteMaster : MasterPage
{
public string SayHello()
{
return "Hello";
}
}
}
Add the MasterType directive to the top of your content page
<%@ Page Title="Home Page" Language="C#" MasterPageFile="~/Site.Master" EnableEventValidation="false" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="WebApplication1._Default" %>
<%@ MasterType TypeName="WebApplication1.SiteMaster" %>
In your page you can now access the "SayHello" function on your master page
protected void Page_Load(object sender, EventArgs e)
{
string text = Master.SayHello();
}
If you don't want to use the MasterType you can still acccess the master page code but you have to cast yourself
var master = (SiteMaster) Master;
string text = master.SayHello();
If you have code in the master page that you need to access from non-page classes then the master page is the wrong place for that code. Put it in its own class rather than the master page.
|
|
|
|
|
Thank you so much.
I will try this.
Yes I have code 2 methods in Master page, which i need to access from content pages, But i will have more than 50 Content Pages. So i am planning to declare in Master and call from other pages.
What will be the best approach for this.
Actually I am thinking to write the methods in Class Library and access from all the aspx.cs pages. But the methods are calling one of the control in the Master page like this.Master.CtrlName. But this i couldnt write in my class library class file.
Thanks Again.
|
|
|
|
|
Add an interface to your class library which exposes the relevant methods.
Have the methods in your class library take an instance of that interface as a parameter, and call the methods on it.
Make the master page implement that interface.
Pass the master page to the class library methods.
Class library:
public interface ISiteMaster
{
void DoSomething();
string ReturnSomething();
}
public class SomeClass
{
public string Foo(ISiteMaster master)
{
master.DoSomething();
return master.ReturnSomething();
}
} Web application:
public partial class SiteMaster : MasterPage, ISiteMaster
{
public void DoSomething() { ... }
public string ReturnSomething() { ... }
}
public partial class HomePage : Page
{
protected void Page_Load(object sender, EventArgs e)
{
var helper = new SomeClass();
string value = helper.Foo(Master);
string value = helper.Foo((ISiteMaster)Master);
}
}
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Hello Friends,
I have asp.net website and have few class libraries in the same solution.
I am trying to store a database retrieved datatable (it contains only one column) into Array variable and assigning the array into Session.
This code is in my aspx.cs page.
<b>Code is aspx.cs below:</b>
DataRow[] foundAuthors = dtPermission.Select("Value = '" + Permission + "'");
if (foundAuthors.Length != 0)
{
ArrayList permlist = new ArrayList();
foreach (DataRow dr in dtPermission.Rows)
{
permlist.Add(dr["Value"].ToString());
}
SessionHandler s = new SessionHandler();
s.SetSession(permlist, "sPermList");
I have the following code in the class library. But in this code the session value i am not sure how to assign as array list in test method. currently it is showing as string and not working. Please help.
<b>Class Library Code:</b>
public class SessionHandler : IRequiresSessionState
{
public SessionHandler() { }
public object GetSession(string key)
{
object session = HttpContext.Current.Session[key];
return session;
}
public void SetSession(object data, string key)
{
HttpContext.Current.Session.Add(key, data);
}
public bool Test(string sessionKey,string perValue)
{
string ss = GetSession(sessionKey).ToString();
--Here need to assign session value to array list and compare the perValue against array list (or) if we can directly compare session stored value and return true / false
return true;
}
}
Thanks in Advance,
Priya.
-- modified 14-Nov-19 6:23am.
|
|
|
|
|
How about:
public bool Test(string sessionKey, string perValue)
{
System.Collections.IEnumerable list = (System.Collections.IEnumerable)GetSession(sessionKey);
foreach (string item in list)
{
if (item == perValue)
{
return true;
}
}
return false;
}NB: You should avoid using ArrayList. It's an old collection from before the introduction of generics. Use List<T> instead.
NB2: The IRequiresSessionState on your SessionHandler class won't make any difference. That interface is only used on the IHttpHandler which handles the request. For a WebForms page, that is controlled by setting the EnableSessionState property in the <%@ Page ... %> directive.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Hello Richard,
Thanks lot and lot. It worked like charm!! This is saved my time, i was searching for a day on this.
Reg. the Note 1 : I agree and follow that.
Reg. the Note 2, I am not really understanding, if you could elaborate that will be great help to me. Is the approach I am following will hit performance,
Thanks in Advance.
Priya.
|
|
|
|
|
Every request to your application is handled by an instance of a class which implements the IHttpHandler interface[^].
For a WebForms page (.aspx), that class will be derived from the System.Web.UI.Page class[^]. Session state is controlled by setting the EnableSessionState attribute on the @ Page directive[^]. It can be set to "True", "False", or "ReadOnly". The compiler will automatically implement the correct session state interface on the generated class for you.
For other handlers, session state is enabled or disabled depending on whether the handler class implements the IRequiresSessionState interface[^], or the IReadOnlySessionState interface[^] if it doesn't add or update any session data.
Implementing the IRequiresSessionState interface in a class which is not the handler for the current request will have no effect.
ASP.NET Session State Overview | Microsoft Docs[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Thank you for brief explanation.
|
|
|
|
|
what is major difference between blazor server app and asp.net mvc razor app?
=====================================================
The grass is always greener on the other side of the fence
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
