Technical debate (especially ASP. NET web forms and ASP. net mvc)

Technical debates are endless in blogs and Twitter, which cover every developer community. Every language, framework, tool, and platform may inevitably have at least a few arguments at a specific time.

The following are my observations on the technical debate over the years, as well as my recent observations, especially on ASP. net web forms and ASP. net MVC.

Overall Observation on technical debate

The following are some observations without any specific technical arguments:

A) developers like to argue enthusiastically and compare languages, frameworks, APIs, and tools. This is true for every programming community (. NET, Java, PHP, C ++, Ruby, Python, and so on. I think you can look at this type of religious technical debate in two ways:

1. These arguments are sometimes annoying and often a waste of time.
2. These arguments are often a sign of a healthy and active community (because passion means that both parties are deeply concerned, far better than being uninterested (apathy )).

Personally, I think both are right.

B) there is no one right way to develop anything )". As an interview opening question, I sometimes ask the participants to sort a group of numbers in the most efficient way they can. Most people do not do well. This is generally not because they do not know sorting algorithms, but because they never remember to ask about the scenarios and requirements behind them. These actions are crucial to the most efficient way of understanding. What is the number sequence? How high is the random degree of a typical digital sequence? (Are most of them sorted? What is the difference between numbers? Are numbers unique? Are duplicate numbers clustered ?) How high is the parallelism of computer architecture? Can I allocate memory or the memory must be a constant as part of the sorting? And so on. These are important questions, because the most efficient and optimal sorting method for a group of numbers depends on the understanding of these answers.

When people claim that a programming problem has only one and only "correct path", they almost always assume a fixed set of requirements/scenarios/inputs, this is rarely the best for every scenario or for every developer. As we all know, most programming problems are much more complicated than sorting a group of numbers.

C) Excellent developers can use poor tools/frameworks to create excellent applications. Poor developers can use excellent tools/frameworks to create business applications. Be cautious when making too broad assumptions (good or bad) about the quality of the application you are building based on the tools/frameworks you are using.

D) Developers (good and bad) can become more powerful by extending themselves and learning new ideas and methods. In real time, they don't directly use new things. Learning this action itself can make them sharp in a positive way.

E) in the technology industry, changes are permanent. Changes can be frightening. But whether you get overwhelmed depends on whether you want to overwhelm yourself. Don't worry too much about the need to stop and suddenly learn a bunch of new things. You seldom need to do that. The best way to avoid being overwhelmed is to be pragmatic, maintain a considerable understanding of a wide range of things at a high level (not just technology and tools, but also methodology), and be confident that, if learning a new technology is very important, most of your existing development skills can be transferred and helpful. In any case, syntaxes and APIs are few of the most important things for development. problems are solved, customer resonance and interaction (customer empathy/engagement ), it is more valuable to be able to focus on a project and be well trained.

F) below are some tips that I will occasionally give my development team members for collaboration and communication with others:

1. Tell others that they are stupid, and you seldom win arguments, no matter how good or persuasive your explanation of their IQ problems is.
2. Someone, somewhere in the world, is smarter than you.-Don't always assume they are not in the same room with you.
3. People you communicate with will often forget the praise you have given them, and will often remember the previous insults.-So be careful when talking, otherwise you will suffer from endless troubles (come back to haunt you later ).
4. People can change their minds, and they will also change their minds.-Do not stick to your own opinions in the debate. If they change their minds, do not be complacent or discriminate against them.

G) when I hear people complain that programming abstraction is not good, I always find it a bit ridiculous. Especially when these complaints are published by bloggers, think that the Blog content is displayed in HTML, CSS-based style, JavaScript-based interaction, HTTP transmission online, and application programming in advanced languages on the server end, using object-oriented, the garbage collection framework runs on the interpreted or jit-compiled bytecode runtime. The Blog content and comments are ultimately stored in the relational database, it is accessed through SQL query strings. All of these are run in the VM on the host server, while the OS in the VM allocates the memory based on the process boundaries in the kernel mode and user mode, and uses thread scheduling, use signals to trigger device events and abstract storage APIs for hard disk persistence. Wait for the next time you read "Comparison Between orm and stored procedures" or "is the server control good or bad ?" It is worth recalling all these things in your mind. The more interesting arguments are the best abstraction of specific issues.

H) The history of programming debate is a long infinite loop. In fact, most programming ideas have been solved many times. Whether it is true or false, many of the issues we have argued today have been resolved in LISP and smalltalk a long time ago. It is ridiculous that although many things have been created elegantly, these two languages are not used much. Let's think about it.

Some Comments on ASP. NET web forms/ASP. net mvc contention:

The following are some comments about some of the arguments I have recently seen in the community. These arguments are about ASP. NET web forms and ASP. NET MVC which is the best solution:

A) web forms and MVC are two solutions for building ASP. NET applications. They are both good choices. Depending on the application requirements and the background of the team members involved in development, each solution can be the "Best Choice" for specific problems ". You can use either of the two to build excellent applications. You can also use either of them to build bad applications. Whether you are a good developer or a poor developer doesn't depend on what you choose. You can use both of them, either absolutely good or useless.

B) the ASP. NET and Visual Studio development teams have invested a lot of resources in both web forms and MVC, so no one will disappear. Both of them will be released in the next few months. ASP. net 4 contains major updates to web forms (Clean clientid and CSS-based logo output, smaller viewstate, URL orientation, new data and report controls, new Dynamic Data features, new SEO APIs, new vs designer and project Improvement ). ASP. ASP. NET 4 will be released at the same time. net MVC 2, which contains major updates (strong auxiliary methods, model verification, multi-region, better support for scaffolding, asynchronous support, more auxiliary methods such as APIS ). Don't worry, either of them will be dead or you must turn to another one. I suspect that after all of us have been dead for a long time, some servers on the Internet are still running applications based on ASP. NET web forms and ASP. NET MVC.

C) The code/infrastructure/APIs shared between web forms and MVC is far more than any one of the parties involved in the debate mentioned,-authentication, authorization, members, roles, URL-oriented, cache, session Status, user information, configuration, compilation ,. aspx webpage ,. master File ,. ascx file, global. asax, request/reply/cookie APIs, health monitoring, process model, tracking, deployment, Ajax, and so on. No matter how you build your UI, all the common things you have learned are equally effective. In the future, we will continue to invest a lot of resources to build the core ASP for web forms and MVC. NET features (such as URL-oriented, deployment, output cache, and we add to ASP.. Net 4 ).

D) I often find it a bit ridiculous to argue about the suitability and abstraction of programming models. Both web forms and MVC are programming Web framework abstraction, which is built on a wider framework abstraction. They are programmed in advanced programming languages and run on the runtime engine abstraction, the runtime engine abstraction itself runs on the massive abstraction called OS. What you create with web forms and MVC is HTML/CSS/JavaScript (all abstractions are persistent as text, transmitted over HTTP, while HTTP is another high-level protocol abstraction ).

The interesting question of this debate is not whether the abstraction is good or bad,WhichAbstract: You feel the most natural. Which abstraction matches the needs, scenarios, and developers of your project best.

E) We will make a very significant update to www.asp.net. As part of the update, we will post more end to end tutorials/content (both web forms and MVC ). We will also provide tutorials and guidance to help developers quickly evaluate the web forms and MVC solutions, easily learn the working principles of the two, and quickly decide which one feels best. This will help new ASP. NET developers and those who already know web forms or MVC to understand and evaluate the two solutions and decide which one they want to use.

F) decide whether you want to use web forms or MVC for a project, and then you will be happy with this decision. Both are good choices. Respect the choices made by others. They hope to make a good choice and make smooth progress. Remember, they know more about their own business/skills than you know. Similarly, you may want to know more about your own business/skills than they do.

G) sharing ideas and best practices with others is a major part of blogs, forums, email lists, and communities. They succeed when people know that their ideas will not be completely done and they will be treated with respect. Please be constructive, not mean. Please teach, not lessons. Remember, you must have a teacher.

I hope this article will help you,

Scott

 

Original ENGLISH

[In addition to blogging, I am also now using Twitter for quick updates and to share links. Follow me:Twitter.com/scottgu]

Technical debates are discussed endlessly within the blog-o-sphere/Twitter-verse, And they range within SS every developer community. each language, framework, tool, and platform inevitably has at least a few going on at any particle point in time.

Below are a few observations I 've made over the years about technical debates in general, as well as some comments about some of the recent discussions I 've seen recently about the topic of ASP. net web forms and ASP. net MVC in particle.

General observations about technical debates

Below are a few general observations independent of any specific technical debate:

A) Developers love to passionately debate and compare ages, frameworks, APIs, and tools. this is true in every programming community (. net, Java, PHP, C ++, Ruby, Python, etc ). I think you can view these types of religious technical debates in two ways:

1. They are sometimes annoying and often a waste of time.
2. They are often a sign of a healthy and active community (since passion means people care deeply on both sides of a debate, and is far better than apathy ).

Personally I think both points are true.

B) there is never only "one right way" to develop something. as an opening interview question I sometimes ask people to sort an array of numbers in the most efficient way they can. most people don't do well with it. this is usually not because they don't know sort algorithms, but rather because they never think to ask the scenarios and requirements behind it-which is critical to understanding Most efficient way to do it. How big is the sequence of numbers? How random is the typical number sequence (is it sometimes already mostly sorted, how big is the spread of numbers, are the numbers all unique, do duplicates cluster together )? How parallel is the computer architecture? Can you allocate memory as part of the sort or must it be constant? Etc. These are important questions to ask because the most efficient and optimal way to sort an array of numbers depends on understanding the answers.

Login people assert that there is only "one right way" to a programming problem they are almost always assuming a fixed set of requirements/scenarios/inputs-which is rarely optimal for every scenario or every developer. and to state the obvious-most problems in programming are far more complex than sorting an array of numbers.

C) Great developers using bad tools/frameworks can make great apps. bad developers using great tools/frameworks can make bad apps. be very careful about making broad assumptions (good or bad) about the quality of the app you are building based on the tools/frameworks used.

D) Developers (good and bad) can grow stronger by stretching themselves and learning new ideas and approaches. even if they ultimately don't use something new directly, the act of learning it can sharpen them in positive ways.

E) Change is constant in the technology industry. change can be scary. whether you get overwhelmed by change, though, ultimately comes down to whether you let yourself be overwhelmed. don't stress about having to stop and suddenly learn a bunch of new things-rarely do you have. the best approach to avoid being overwhelmed is to be pragmatic, stay reasonably informed about a broad set of things at a high-level (not just technologies and tools but also methodologies ), and have the confidence to know that if it is important to learn a new technology, then your existing development skills will mostly transition and help. syntax and APIs are rarely the most important thing anyway when it comes to development-problem solving, customer empathy/engagement, and the ability to stay focused and disciplined on a project are much more valuable.

F) some guidance I occasionally give people on my team when working and communicating with others:

1. You will rarely win a debate with someone by telling them that they are stupid-no matter how well intentioned or eloquent your explanation of their IQ problems might be.
2. There will always be someone somewhere in the world who is smarter than you-don't always assume that they aren't in the room with you.
3. People you interact with too often forget the praise you give them, and too often remember a past insult-so be judicous in handing them out as they come back to haunt you later.
4. People can and do change their minds-be open to being persuaded in a debate, and neither gloat nor hold it against someone else if they also change their minds.

G) I always find it somewhat ironic when I hear people complain about programming into actions not being good. especially when these complaints are published via blogs-whose content is displayed using HTML, is styled with CSS, made interactive with JavaScript, transported over the wire using HTTP, and implemented on the server with apps written in higher-level languages, using object oriented Gar Bage collected frameworks, running on top of either interpreted or jit-compiled byte code runtimes, and which ultimately store the Blog content and comments in relational databases ultimately accessed via SQL query strings. all of this running within a VM on a hosted server-with the OS within the VM partitioning memory processing SS kernel and user mode process boundaries, scheduling work using threads, Raising device events using signals, and using an abstract storage API fo disk persistence. it is worth keeping all of that in mind the next time you are reading a "ORM vs Stored Procedures" or "server controls-good/bad?" Post. The more interesting debates are about what the best practice actions are for a particle problem.

H) The history of programming debates is one long infinite loop-with most programming ideas having been solved multiple times before. and for what it's worth-seconds of the problems we debate today were long ago solved with lisp and smalltalk. ironically, despite pioneering a number of things quite elegantly, these two ages tend not be used much anymore. go figure.

Some comments specific to ASP. NET web forms/ASP. net mvc debates:

Below are a few comments specific to some of the recent debates that I 've seen going around in the community as to whether a ASP. net web forms or ASP. net MVC based approach is best:

A) web forms and MVC are two approaches for building ASP. net apps. they are both good choices. each can be the "best choice" for a particle solution depending on the requirements of the application and the background of the team members involved. you can build great apps with either. you can build bad apps with either. you are not a good or bad developer depending on what you choose. you can be absolutely great or worthless using both.

B) the ASP. net and Visual Studio teams are investing heavily in both web forms and MVC. neither is going away. both have major releases coming in the months ahead. ASP. net 4 registrdes major updates to web forms (Clean clientids and CSS based markup output, smaller viewstate, URL routing, new data and charting controls, new dynamic data features, new SEO APIs, new vs designer and project improvements, etc, etc ). ASP. net 4 will also ship with ASP. net MVC 2 which also includes major updates (stronugly typed helpers, model validation, areas, better scaffolding, async support, more helper APIs, etc, etc ). don't angst about either being a dead-end or something you have to change. I suspect that long after we are all dead and gone there will be servers somewhere on the Internet still running both ASP. net web forms and ASP. net MVC Based apps.

C) web forms and MVC share far more code/infrastructure/APIs than anyone on either side of any debate about them ever mentions-authentication, authorization, membership, roles, URL routing, caching, session state, profiles, configuration, compilation ,. aspx pages ,. master files ,. ascx files, global. asax, request/response/cookie APIs, health monitoring, process model, tracing, deployment, Ajax, etc. all of that common stuff you learn is equally valid regardless of how you construct your UI. going forward we'll continue to invest heavily in building core ASP. NET features that work for both web forms and MVC (like the URL routing, deployment, output caching, and dataannotations for validation features we are adding with ASP. net 4 ).

D) I often find debates around und programming model appropriateness and have actions a little silly. both web forms and MVC are programming Web framework extends actions, built on top of a broader framework extends action, programmed with higher level programming extends ages, running on top of a execution engine charge action that itself is running on top of a giant charge action called an OS. what you are creating with each is HTML/CSS/JavaScript (all activities actions persisted as text, transmitted over HTTP-another higher level protocol under action ).

The interesting question to debate is not whether into actions are good or not-but ratherWhichDefine actions feels most natural to you, and which map best to the requirements/scenarios/developers of your project.

E) we are about to do a pretty major update to the www.asp.net site. as part of that we will be posting more end to end tutorials/content (for both web forms and MVC ). we will also be providing tutorials and guidance that will help developers quickly evaluate both the web forms and MVC approach, easily learn the basics about how both work, and quickly determine which one feels best for them to use. this will make it easy for developers new to ASP. net, as well as developers who already know either web forms or MVC, to understand evaluate the two approaches and decide which they want to use.

F) Decide on a project about whether you want to use web forms or MVC and feel good about it. both can be good choices. respect the choices other people make-the choice they have made is also hopefully a good one that works well for them. keep in mind that in all likelihood they know a lot more about their own business/skills than you do. likewise you hopefully know a lot more about your own business/skills than they do.

G) share ideas and best practices with others. that is a big part of what blogs, forums, listservs and community is all about. what makes them work great is when people know that their ideas aren't going to be ripped to shreds, and that they will be treated with respect. be constructive, not snarky. teach, don't lecture. remember there is always someone else out there who you can also learn from.

Hope this helps,

Scott