Why ASP.NET MVC\Core ???
-
In researching my options for a new development endeavor based on my current, desktop, document management system for individuals, I once again turned to the ASP.NET MVC paradigm as consideration. Having worked on a very large ASP.NET MVC application a number of years ago, I was already quite familiar with the general foundations of the MVC paradigm within the ASP.NET development environment. Thinking that this environment is the way to go for new web application, I began to re-familiarize myself with the technologies involved since I have been primarily working in WPF for the past several years. After spending several weeks relearning these technologies I came to the same conclusion I did those years ago that the ASP.NET MVC paradigm is nothing more than an overly complex, inefficient way to build database intensive applications. The moment one needs to include complex, interface components, ASP.NET MVC provides little efficiency in doing so. As a result, to do this, one has to turn to large amounts of JavaScript frameworks and control suites to support such interfaces along with all the arcane techniques in coding the support for such interfaces. Currently, the ASP.NET MVC\Core tools environment has exploded from a limited set of useful adjunct tools (ie: jQuery) to such a plethora of such tools that one new to this type of development would have a very difficult time in attempting to understand where to start. As one who has done an extensive amount of ASP.NET WebForms development, I often wonder what drove our profession to turn to such a complex architecture as ASP.NET MVC and now ASP.NET Core (which is just another name for MVC). It seems to me, that my colleagues, young and old, were complacent enough to allow our primary development tools vendor, Microsoft, to set the conditions and terms of our development futures by simply accepting their technology roadmaps for the future. So how's that been working out for everyone? In a recent announcement, Microsoft has stated that both WebForms and Windows Communication Foundation will not be supported in the newer releases of the .NET Core Frameworks. Refining the .NET Framework is certainly understandable but eliminating core technologies which has thousands applications relying on the original technologies is certainly draconian to the companies that require such ongoing support. And what are they to do; invest hundreds of thousands of dollars to rewrite applications that are working well enough to be maintained in their original form sim
My apologies for not replying sooner to the people who commented on my post. However, I have been involved in quite a bit of in-depth testing of the newer web development tools on offer by Microsoft, which includes ASP.NET MVC, Blazor, and Razor pages. I have a standard that I always go by when it comes to software tools... If it can't be figured out in 20 minutes it is not worth the effort. I use this standard as a basis for how well the corresponding documentation to the tools presents itself to the developer while allowing the developer to quickly set up scenarios that he or she would require for their projected endeavor. What I found in my testing is that the web development environments now being offered by Microsoft are almost schizophrenic in nature while being accompanied by such erratic documentation from a wide range of sources as to be almost incomprehensible. So much of the documentation provides for so many differing implementations of the same thing that a developer would be more than confused as to which one is best for his or her circumstances in addition to which implementation actually works consistently. As it regards ASP.NET WebForms being merely a prototyping software tool. This is completely false. WebForms was designed to be similar to current desktop development endeavors with an event driven environment. However, it did not fully encapsulate the concept of the thin-client, which was a radical departure from desktop applications where such clients were usually quite heavy. The thin-client model became popular in the late 1990s and early 2000s as a result of the n-tiered client-server architecture then being promoted. In my view, the thin-client concept was and still is far superior to the now thick-client emphasis in development. The thin-client was there to promote only code on the front-end that dealt with the display and retrieval aspects of the interface, leaving the rest to various tiers in the overall application\system. Such a distributed nature of this type of development was and still is the primary factor in making distributed systems that could scale with very high levels of concurrency. The person who replied that ASP.NET MVC could be made server-side like WebForms may have been able to accomplish such a development but it is not based upon the inherent MVC paradigm if such a development breaks with it, which is strictly based on a middle-tier model along with its corresponding middle-tier controller. The view then is used strictly for the interface.
-
My apologies for not replying sooner to the people who commented on my post. However, I have been involved in quite a bit of in-depth testing of the newer web development tools on offer by Microsoft, which includes ASP.NET MVC, Blazor, and Razor pages. I have a standard that I always go by when it comes to software tools... If it can't be figured out in 20 minutes it is not worth the effort. I use this standard as a basis for how well the corresponding documentation to the tools presents itself to the developer while allowing the developer to quickly set up scenarios that he or she would require for their projected endeavor. What I found in my testing is that the web development environments now being offered by Microsoft are almost schizophrenic in nature while being accompanied by such erratic documentation from a wide range of sources as to be almost incomprehensible. So much of the documentation provides for so many differing implementations of the same thing that a developer would be more than confused as to which one is best for his or her circumstances in addition to which implementation actually works consistently. As it regards ASP.NET WebForms being merely a prototyping software tool. This is completely false. WebForms was designed to be similar to current desktop development endeavors with an event driven environment. However, it did not fully encapsulate the concept of the thin-client, which was a radical departure from desktop applications where such clients were usually quite heavy. The thin-client model became popular in the late 1990s and early 2000s as a result of the n-tiered client-server architecture then being promoted. In my view, the thin-client concept was and still is far superior to the now thick-client emphasis in development. The thin-client was there to promote only code on the front-end that dealt with the display and retrieval aspects of the interface, leaving the rest to various tiers in the overall application\system. Such a distributed nature of this type of development was and still is the primary factor in making distributed systems that could scale with very high levels of concurrency. The person who replied that ASP.NET MVC could be made server-side like WebForms may have been able to accomplish such a development but it is not based upon the inherent MVC paradigm if such a development breaks with it, which is strictly based on a middle-tier model along with its corresponding middle-tier controller. The view then is used strictly for the interface.
Steve Naidamast wrote:
There is no allowance for pre-made components such as is found with WebForms to easily work with the front-end and middle-tiers of such an application, unless you consider the mass of JavaScript comprised components that currently make up the MVC front-end arena.
@Html.TextBoxFor(...)
What do you call that? You can also write your own html extensions so you can have
@Html.LoginForm()
or a custom grid that outputs html with edit capabilities. There's nothing stopping you writing componentised code. As I said in my other reply, yes the state is handled differently but MVC is a different paradigm so of course some things need to be done in a slightly different way. I spend my days working on MVC based CMS systems, I literally spend all day writing re-usable components that can be placed anywhere on a page so when you tell me this can't be done or is too hard\too much work then I have to be honest and think the issues is that you just don't know MVC well enough or you are struggling to change your thought processes. One of the biggest problems when MVC came out is that everyone wanted to continue doing WebForms, but just using MVC. You can't do that, you have to change your mindset, your way of dealing with issues, solving problems and implementing solutions.
Steve Naidamast wrote:
The idea that was promoted in one of the replies here that developers should have a greater understanding of how the Internet works in order to develop better applications is complete nonsense. That is not our job as software engineers and developers. Our job is to develop quality applications; not worry about what is going on underneath the hood as they say.
Wow. "Why should I have to learn how the human body works to become a surgeon? That's not my job, my job is to simply take the old heart out and put this new one in."
Steve Naidamast wrote:
I am finding that people who promote the ASP.NET MVC style of development appear not to have been exposed to its drastic limitations when under stress with the development large-scale, complex, database, intensive applications.
I've used MVC on database based systems, web API based systems, index based systems....you name it I've done it. There is nothing inherent in MVC that stops you working with these things, and ag
-
Steve Naidamast wrote:
There is no allowance for pre-made components such as is found with WebForms to easily work with the front-end and middle-tiers of such an application, unless you consider the mass of JavaScript comprised components that currently make up the MVC front-end arena.
@Html.TextBoxFor(...)
What do you call that? You can also write your own html extensions so you can have
@Html.LoginForm()
or a custom grid that outputs html with edit capabilities. There's nothing stopping you writing componentised code. As I said in my other reply, yes the state is handled differently but MVC is a different paradigm so of course some things need to be done in a slightly different way. I spend my days working on MVC based CMS systems, I literally spend all day writing re-usable components that can be placed anywhere on a page so when you tell me this can't be done or is too hard\too much work then I have to be honest and think the issues is that you just don't know MVC well enough or you are struggling to change your thought processes. One of the biggest problems when MVC came out is that everyone wanted to continue doing WebForms, but just using MVC. You can't do that, you have to change your mindset, your way of dealing with issues, solving problems and implementing solutions.
Steve Naidamast wrote:
The idea that was promoted in one of the replies here that developers should have a greater understanding of how the Internet works in order to develop better applications is complete nonsense. That is not our job as software engineers and developers. Our job is to develop quality applications; not worry about what is going on underneath the hood as they say.
Wow. "Why should I have to learn how the human body works to become a surgeon? That's not my job, my job is to simply take the old heart out and put this new one in."
Steve Naidamast wrote:
I am finding that people who promote the ASP.NET MVC style of development appear not to have been exposed to its drastic limitations when under stress with the development large-scale, complex, database, intensive applications.
I've used MVC on database based systems, web API based systems, index based systems....you name it I've done it. There is nothing inherent in MVC that stops you working with these things, and ag
First, you are not being asked to become a surgeon so your analogy is not very relevant. Second, why should I have to bother writing HTML extensions when that is taking time away from my core development endeavor, which is completing an application? And no, available HTML Helpers are not the equivalent of more feature rich server based components. But you are correct about me not wanting to change my thought processes to understand and implement ASP.NET MVC applications. Been there, done that. Didn't like it and nor did I find it very efficient. Your contention is that we have to completely upend our thinking in order to develop with ASP.NET MVC. Why? What is the purpose of having to go to a lower level of development, to do much more as a result, subsequently taking more time to do so. Doing this is certainly not providing any organization with any cost benefits in terms of development endeavors. Would you give up developing in C# or VB.NET to suddenly find you have to do everything in C++? Well, that is what is being more or less asked of web developers today. CMS systems are not database intensive systems such as what is found in the financial industry where I worked for over 20 years in my career. You think that with brutal deadlines you are going to want to tinker with something like ASP.NET MVC when you need to get development done yesterday? I don't think so. And your experience in no way outpaces mine as I have done as much if not more than you have across three distinct eras in the Information Technology profession. The problem is that many developers who are detailed oriented seemed to have inherently gravitated to the ASP.NET MVC paradigm simply due its greater complexities. I can understand that as I watched one engineer develop an entire JavaScript Treeview control from scratch instead of using one of the available components. his reasoning was that he could do a better job than the components available at the time. That was all well and good but doing what he did cost the project three weeks in time. And from what I have seen this appears to be perfectly acceptable to the ASP.NET MVC promoters. You admitted to some of this yourself. But that is not your job if you are a software engineer working to create line of business applications. Your job is to get the application completed as quickly and efficiently as possible most often within limited deadlines. And maybe it is your thought processing that requires adjusting if you do not understand this...
-
First, you are not being asked to become a surgeon so your analogy is not very relevant. Second, why should I have to bother writing HTML extensions when that is taking time away from my core development endeavor, which is completing an application? And no, available HTML Helpers are not the equivalent of more feature rich server based components. But you are correct about me not wanting to change my thought processes to understand and implement ASP.NET MVC applications. Been there, done that. Didn't like it and nor did I find it very efficient. Your contention is that we have to completely upend our thinking in order to develop with ASP.NET MVC. Why? What is the purpose of having to go to a lower level of development, to do much more as a result, subsequently taking more time to do so. Doing this is certainly not providing any organization with any cost benefits in terms of development endeavors. Would you give up developing in C# or VB.NET to suddenly find you have to do everything in C++? Well, that is what is being more or less asked of web developers today. CMS systems are not database intensive systems such as what is found in the financial industry where I worked for over 20 years in my career. You think that with brutal deadlines you are going to want to tinker with something like ASP.NET MVC when you need to get development done yesterday? I don't think so. And your experience in no way outpaces mine as I have done as much if not more than you have across three distinct eras in the Information Technology profession. The problem is that many developers who are detailed oriented seemed to have inherently gravitated to the ASP.NET MVC paradigm simply due its greater complexities. I can understand that as I watched one engineer develop an entire JavaScript Treeview control from scratch instead of using one of the available components. his reasoning was that he could do a better job than the components available at the time. That was all well and good but doing what he did cost the project three weeks in time. And from what I have seen this appears to be perfectly acceptable to the ASP.NET MVC promoters. You admitted to some of this yourself. But that is not your job if you are a software engineer working to create line of business applications. Your job is to get the application completed as quickly and efficiently as possible most often within limited deadlines. And maybe it is your thought processing that requires adjusting if you do not understand this...
Steve Naidamast wrote:
First, you are not being asked to become a surgeon so your analogy is not very relevant
"Why should I understand gravity, frictional forces, stress points of materials and so on to become a structural engineer? That's not my job, my job is just to build a bridge that can carry traffic."
Steve Naidamast wrote:
Second, why should I have to bother writing HTML extensions when that is taking time away from my core development endeavor, which is completing an application?
Because often what you want to use isn't available off the shelf and you have to write it yourself. What's important is that if you have to, that you can.
Steve Naidamast wrote:
Your contention is that we have to completely upend our thinking in order to develop with ASP.NET MVC. Why?
Because it's a different paradigm. WebForms is server-based, state-managed, event-driven so people think in terms of "when I do this thing code runs on the server and at that point I interrogate and update state and everything else happens by magic". With MVC you need to think more about the separation of your components, you then need to output html\views that model binding can convert to a view model in your controller, your controller then has to best decide what domain model needs interacted with, and your domain model needs to know how to update the state of your system (be that amending database tables or whatever else). So rather than having one component responsible for multiple things, you need to be more granular in your thinking, and this ultimately results in better, more reusable, and testable code. The trade-off is that it does indeed often need a little more effort. However if the speed of development is the only metric you are working off then fine, MVC probably isn't for you, but that's your experience and quite a narrow one. Most big projects have many more metrics than speed of development.
Steve Naidamast wrote:
CMS systems are not database intensive systems such as what is found in the financial industry where I worked for over 20 years in my career
My point about CMS systems is that they involve a lot of re-usable components, the thing you say MVC struggles to do. I have also worked with more traditionally database-intensive systems, *and* API heavy CMS systems and
-
Thank the great Ghu I retired before I had to get involved with the current kludge of web tech. I still have not forgiven them for the death of Silverlight! I did think I would take the time to learn new tech out of interest but anything to do with the web just fells so 80's. Marketing, especially well funded and supported marketing will always triumph over good product and when your primary tool supplier decides on a technology there are not many who will be able to break away from that supplier.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
Mycroft... A fan of the great detective are we? :) In any event, I completely agree with you regarding the ASP.NET MVC environment and all the other subsequent tools that developers apply to it. It did not encourage me to retire when I did in 2014 but I was seeing the writing on the walls. As I believe I mentioned in my original post, most developers were actually aghast at the basis for the ASP.NET MVC paradigm as most remarked that it returned our development backwards to the 1990s and Classic ASP. To date, this is exactly what the new Razor Pages software provides; files mixed with markup and C# code (instead of VBScript). I cannot for the life of me understand why so many developers turned against ASP.NET WebForms when it was capable of so much. The only additional tools we required to work with WebForms was a good foundation in JavaScript and jQuery and possibly a good third-party tools provider. That was it... And still is. It appears that when dealing with the younger generations in general they are no longer capable of understanding anything that is beyond their scope of perspectives. But they are sure fast to adopt whatever the technical vendors provide them. Maybe I am getting too old but there is fight left in me yet.
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
Steve Naidamast wrote:
First, you are not being asked to become a surgeon so your analogy is not very relevant
"Why should I understand gravity, frictional forces, stress points of materials and so on to become a structural engineer? That's not my job, my job is just to build a bridge that can carry traffic."
Steve Naidamast wrote:
Second, why should I have to bother writing HTML extensions when that is taking time away from my core development endeavor, which is completing an application?
Because often what you want to use isn't available off the shelf and you have to write it yourself. What's important is that if you have to, that you can.
Steve Naidamast wrote:
Your contention is that we have to completely upend our thinking in order to develop with ASP.NET MVC. Why?
Because it's a different paradigm. WebForms is server-based, state-managed, event-driven so people think in terms of "when I do this thing code runs on the server and at that point I interrogate and update state and everything else happens by magic". With MVC you need to think more about the separation of your components, you then need to output html\views that model binding can convert to a view model in your controller, your controller then has to best decide what domain model needs interacted with, and your domain model needs to know how to update the state of your system (be that amending database tables or whatever else). So rather than having one component responsible for multiple things, you need to be more granular in your thinking, and this ultimately results in better, more reusable, and testable code. The trade-off is that it does indeed often need a little more effort. However if the speed of development is the only metric you are working off then fine, MVC probably isn't for you, but that's your experience and quite a narrow one. Most big projects have many more metrics than speed of development.
Steve Naidamast wrote:
CMS systems are not database intensive systems such as what is found in the financial industry where I worked for over 20 years in my career
My point about CMS systems is that they involve a lot of re-usable components, the thing you say MVC struggles to do. I have also worked with more traditionally database-intensive systems, *and* API heavy CMS systems and
I agree with your final comments as to what I experienced in my career in terms of the technical management I worked under in which practically all of these people were incompetent. However, I worked in many companies and corporations both as consultant and an employee across a large spectrum of industries. So unless something miraculous has happened in the management suites of the United States, I really do not see what I experienced or that of many of my colleagues as no longer the norm considering I only retired in 2014. Maybe you are privileged to work in a company or companies where quality software design takes precedence over deadlines and the like but I never have. And trying to change such technical management is a complete impossibility considering that most are arrogant, incompetents who do not see the need to go up against their own management. The fact that you suggested such a proposition demonstrates your lack of experience in the brutal, working world of Information Technology. Anyone who has had a wide breadth of industry experience under the belts would never say such a thing no matter how long they may have been a professional. Aside from this it does not appear you have actually read what I have been saying but instead have looked to simply disagree with it. I came up in the field when 4th generation development was a thing and ease-of-use was a primary motivation for Microsoft. When Java was introduced it was laughed at not only due to its massive complexity but the near impossibility of doing anything with it easily. Though this environment has gained a substantial foothold in our profession and it has come a long way, it still has many detractors for the original reasons. Should they change their thought processes also? The ASP.NET MVC environment and its subsequent add-on environments such as Blazor and Razor Pages to me, all appear to be nothing but added complexity for complexity's sake in what seems like an effort to mimic Java's original complexities. Our side of the profession is after all mimicking what Java web development always had, the MVC paradigm. I don't doubt that ASP.NET MVC can be more efficient than WebForms but at what cost? Simply because you are doing well with it does not mean that everyone is. Currently there is a 72% job dissatisfaction rating in our profession according to one recent survey taken just a few months ago. And many current development professionals are not very happy with the current web development environments they are contendi
-
I agree with your final comments as to what I experienced in my career in terms of the technical management I worked under in which practically all of these people were incompetent. However, I worked in many companies and corporations both as consultant and an employee across a large spectrum of industries. So unless something miraculous has happened in the management suites of the United States, I really do not see what I experienced or that of many of my colleagues as no longer the norm considering I only retired in 2014. Maybe you are privileged to work in a company or companies where quality software design takes precedence over deadlines and the like but I never have. And trying to change such technical management is a complete impossibility considering that most are arrogant, incompetents who do not see the need to go up against their own management. The fact that you suggested such a proposition demonstrates your lack of experience in the brutal, working world of Information Technology. Anyone who has had a wide breadth of industry experience under the belts would never say such a thing no matter how long they may have been a professional. Aside from this it does not appear you have actually read what I have been saying but instead have looked to simply disagree with it. I came up in the field when 4th generation development was a thing and ease-of-use was a primary motivation for Microsoft. When Java was introduced it was laughed at not only due to its massive complexity but the near impossibility of doing anything with it easily. Though this environment has gained a substantial foothold in our profession and it has come a long way, it still has many detractors for the original reasons. Should they change their thought processes also? The ASP.NET MVC environment and its subsequent add-on environments such as Blazor and Razor Pages to me, all appear to be nothing but added complexity for complexity's sake in what seems like an effort to mimic Java's original complexities. Our side of the profession is after all mimicking what Java web development always had, the MVC paradigm. I don't doubt that ASP.NET MVC can be more efficient than WebForms but at what cost? Simply because you are doing well with it does not mean that everyone is. Currently there is a 72% job dissatisfaction rating in our profession according to one recent survey taken just a few months ago. And many current development professionals are not very happy with the current web development environments they are contendi
Steve Naidamast wrote:
Maybe you are privileged to work in a company or companies where quality software design takes precedence over deadlines and the like but I never have
I've worked in all sorts...I've worked in places where time is everything, and I've worked in places where they just want the job done right, and everything in between. I guess that's just one of the pitfalls of my inexperience ;)
-
Mycroft... A fan of the great detective are we? :) In any event, I completely agree with you regarding the ASP.NET MVC environment and all the other subsequent tools that developers apply to it. It did not encourage me to retire when I did in 2014 but I was seeing the writing on the walls. As I believe I mentioned in my original post, most developers were actually aghast at the basis for the ASP.NET MVC paradigm as most remarked that it returned our development backwards to the 1990s and Classic ASP. To date, this is exactly what the new Razor Pages software provides; files mixed with markup and C# code (instead of VBScript). I cannot for the life of me understand why so many developers turned against ASP.NET WebForms when it was capable of so much. The only additional tools we required to work with WebForms was a good foundation in JavaScript and jQuery and possibly a good third-party tools provider. That was it... And still is. It appears that when dealing with the younger generations in general they are no longer capable of understanding anything that is beyond their scope of perspectives. But they are sure fast to adopt whatever the technical vendors provide them. Maybe I am getting too old but there is fight left in me yet.
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
Steve Naidamast wrote:
A fan of the great detective are we
No that was the name of the computer in The Moon is a Harsh Mistress :-O
Steve Naidamast wrote:
but there is fight left in me yet
Tilting at windmills more likely!
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
Steve Naidamast wrote:
A fan of the great detective are we
No that was the name of the computer in The Moon is a Harsh Mistress :-O
Steve Naidamast wrote:
but there is fight left in me yet
Tilting at windmills more likely!
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
I had that book by Heinlein but I can't remember if I read it or not. It was so long ago... I brought down a lot of bad managers in my time. :)
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
My apologies for not replying sooner to the people who commented on my post. However, I have been involved in quite a bit of in-depth testing of the newer web development tools on offer by Microsoft, which includes ASP.NET MVC, Blazor, and Razor pages. I have a standard that I always go by when it comes to software tools... If it can't be figured out in 20 minutes it is not worth the effort. I use this standard as a basis for how well the corresponding documentation to the tools presents itself to the developer while allowing the developer to quickly set up scenarios that he or she would require for their projected endeavor. What I found in my testing is that the web development environments now being offered by Microsoft are almost schizophrenic in nature while being accompanied by such erratic documentation from a wide range of sources as to be almost incomprehensible. So much of the documentation provides for so many differing implementations of the same thing that a developer would be more than confused as to which one is best for his or her circumstances in addition to which implementation actually works consistently. As it regards ASP.NET WebForms being merely a prototyping software tool. This is completely false. WebForms was designed to be similar to current desktop development endeavors with an event driven environment. However, it did not fully encapsulate the concept of the thin-client, which was a radical departure from desktop applications where such clients were usually quite heavy. The thin-client model became popular in the late 1990s and early 2000s as a result of the n-tiered client-server architecture then being promoted. In my view, the thin-client concept was and still is far superior to the now thick-client emphasis in development. The thin-client was there to promote only code on the front-end that dealt with the display and retrieval aspects of the interface, leaving the rest to various tiers in the overall application\system. Such a distributed nature of this type of development was and still is the primary factor in making distributed systems that could scale with very high levels of concurrency. The person who replied that ASP.NET MVC could be made server-side like WebForms may have been able to accomplish such a development but it is not based upon the inherent MVC paradigm if such a development breaks with it, which is strictly based on a middle-tier model along with its corresponding middle-tier controller. The view then is used strictly for the interface.
Steve Naidamast wrote:
If it can't be figured out in 20 minutes it is not worth the effort.
Found your problem. And ironically you can't spend more than 20 minutes to learn something new but expect people to take that long to read your messages. :laugh:
Social Media - A platform that makes it easier for the crazies to find each other. Everyone is born right handed. Only the strongest overcome it. Fight for left-handed rights and hand equality.