ASP.NET

Re: .Net Core 3.2 Controller, using route and HttpGet attribute with CreatedAtRoute

19-Aug-20 9:39

I'm sort of fuzzy on this here. So I have a HttpPost operation that ends with return Ok(result). I remember reading that I have to add a route to GetOrder in order for CreatedAtRoute to work. I sort of did something stupid and named that api GetAdminOrders so I can secure it with JWT, but added a Route decorator to it so CreatedAtRoute would work.

var result = CreatedAtRoute("GetOrder", new { order.Id }, order);
return Ok(result);

So this didn't work, it didn't return the order back to the client making the call. I just need the order number or Id of the order and not the whole order. Now I'm wondering if I should refactor all of these that I created. I'm really wondering if I got this all wrong here.

[HttpGet("GetAdminOrder/{orderId}"), Authorize(AuthenticationSchemes = AuthSchemes, Policy = AuthPolicies.Admin)]
[Route("{orderId}", Name = "GetOrder")]        
public async Task<GetAdminOrder> GetAdminOrder(string orderId)

If it ain't broke don't fix it
Discover my world at jkirkerx.com

jkirkerx19-Aug-20 11:04

Re: .Net Core 3.2 Controller, using route and HttpGet attribute with CreatedAtRoute

19-Aug-20 11:04

I flipped the 2 around, and changed the route to include the route decorator at the top of the controller.
I guess this route decorator wiped out the first route decorator.

[Produces("application/json")]
[Route("api/[controller]")]
[ApiController]
public class StoreController : ControllerBase

[Route("{orderId}", Name = "api/[controller]/GetOrder")]<br />
[HttpGet("GetAdminOrder/{orderId}"), Authorize(AuthenticationSchemes = AuthSchemes, Policy = AuthPolicies.Admin)]

public async Task<GetAdminOrder> GetAdminOrder(string orderId)

On this, it worked before, but since the .Net Core upgrade, it has changed. Now it sends the order wrapped in Url and Value. So I changed my client to expect a value of "any", and coded the expected order number and token as result.Value.OrderNumber

var result = CreatedAtRoute("GetOrder", new { order.Id }, order);
return Ok(result);

It works, not sure if it's fixed.

If it ain't broke don't fix it
Discover my world at jkirkerx.com

Richard Deeming19-Aug-20 22:58

Richard Deeming

19-Aug-20 22:58

jkirkerx wrote:

CreatedAtRoute("GetOrder", new { order.Id }, order)
...
HttpGet("GetAdminOrder/{orderId}")

IIRC, the parameters passed to CreatedAtRoute need to have the same names as the route parameters.

Your route has orderId, but you parameters has just Id.

Try changing the parameters to match.

You don't need to add both HttpGet and Route attributes.

You should also return the CreatedAtRoute result directly, rather than wrapping it in an Ok result.

return CreatedAtRoute("GetOrder", new { orderId = order.Id }, order);

[HttpGet("GetAdminOrder/{orderId}", Name = "GetOrder"), Authorize(AuthenticationSchemes = AuthSchemes, Policy = AuthPolicies.Admin)]
public async Task<Order> GetAdminOrder(string orderId)

"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer

Re: .Net Core 3.2 Controller, using route and HttpGet attribute with CreatedAtRoute

jkirkerx20-Aug-20 5:33

Re: .Net Core 3.2 Controller, using route and HttpGet attribute with CreatedAtRoute

20-Aug-20 5:33

I didn't think of it like that.

At the beginning before I wrote the JWT auth policies, I tried to make the app really code compact. It was just "GetOrder", then I renamed it to "GetAdminOrder" to reflect JWT Auth. I really need to streamline this naming.

return CreatedAtRoute directly? No need to return Ok. I wonder if using Ok wraps the JSON result in that extra envelope. I'll find out here, takes 10 mins to test it.

I made the code changes, and will give it a try, I'm sure it will work fine. I really don't want the extra route decorator anyways, it was just part of an example of using CreatedAtRoute I picked up over a year ago. I must admit that using CreatedAtRoute is pretty handy.

var result = CreatedAtRoute("GetAdminOrder", new { orderId = order.Id }, order);
return Ok(result);

[HttpGet("GetAdminOrder/{orderId}", Name = "GetOrder"), Authorize(AuthenticationSchemes = AuthSchemes, Policy = AuthPolicies.Admin)]

If it ain't broke don't fix it
Discover my world at jkirkerx.com

jkirkerx21-Aug-20 10:43

21-Aug-20 10:43

That worked out really well!
Thanks Richard

If it ain't broke don't fix it
Discover my world at jkirkerx.com

submit button

Member 1491014319-Aug-20 0:40

19-Aug-20 0:40

kindly help me to solve this issue.....i have Created a Login website - Validation Controls Registration Page but my submit button doesn't show message code i wrote which was:-
Response.Write("YOU HAVE SUCCESSFULLY REGISTERED...!!!!");

Richard MacCutchan19-Aug-20 1:16

Richard MacCutchan

19-Aug-20 1:16

Please edit your question and show the code that has the problem. Without it it is impossible to guess what may be wrong.

Member 1491014319-Aug-20 1:34

19-Aug-20 1:34

button code was one line code and here it is,
Response.Write("you have successfully registered!!!");

once i fill out my web form registration form and i click on submit button nothing is displayed from what i wrote on button code(submit)

Richard MacCutchan19-Aug-20 1:41

Richard MacCutchan

19-Aug-20 1:41

Please read my suggestion again.

Member 1491014319-Aug-20 2:05

19-Aug-20 2:05

but i didn't understand ..kindly break it for me

F-ES Sitecore19-Aug-20 1:37

19-Aug-20 1:37

In addition to what Richard said, asp.net doesn't work like that, response.write is useless in 99% of occasions. If you view the source of your page you'll probably see your message right at the very bottom where it is no use at all. If you want to show a message in a particular place use an empty asp:Label or asp:Literal and when you want the message to be there set the Text of the label\literal to your message, you can also use the Visible property to show\hide it.

Member 1491014319-Aug-20 1:46

19-Aug-20 1:46

Kindly where can i find asp:label? or literal and how am i going to use it? kindly direct me

F-ES Sitecore19-Aug-20 2:46

Label Class (System.Web.UI.WebControls) | Microsoft Docs[^]

19-Aug-20 2:46

Otekpo Emmanuel19-Aug-20 8:56

Otekpo Emmanuel

19-Aug-20 8:56

Just the same way you used to add the button control, same way you will find the Label control and add it.
Or just copy this

ASP.NET

<asp:Label ID="Label1" Text="Label1" runat="server"/>

Then from codebehind, enter this code on your submit button event.

Label1.Text = "You have successfully registered";

ZurdoDev28-Aug-20 5:51

ZurdoDev

28-Aug-20 5:51

How can anyone help you without seeing what you did?

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.

Why ASP.NET MVC\Core ???

Steve Naidamast16-Aug-20 7:38

16-Aug-20 7:38

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 simply because Microsoft no longer wants to support them. That's their job!

When Bill Gates was the CEO of Microsoft, we had a person who more or less was committed to the development community's needs and requirements.
To be sure, he wasn't perfect but for the most part he fell in line with the overall needs of our profession.

In 2010, when Stave Ballmer was starting to take the reins of Microsoft, ASP.NET MVC was introduced to the surprise of many of us ASP.NET WebForms developers who had experience with the Classic ASP development environment. Practically to a person, the reaction to this new paradigm was that of a giant step backwards. Little did we know at that time how truly backwards MVC was considering that its foundations were designed in the 1970s.

The Castle Project for quiet sometime had been freely offering its own ASP.NET MVC Open Source project, MonoRails, but it never found much interest in the Microsoft Development Community. ASP.NET WebForms, even with all its inefficiencies and issues, was still an environment where complex web applications could be easily developed and tested.

But the naysayers for this environment quickly enough got their voices heard and for some reason, many professionals began to listen. The claims by these professionals was that ASP.NET MVC offered developers a brand new environment with much greater control over their interface development processes. But in terms of efficiency and accomplishing actual development, such control was in reality a mirage.

So we gave up easy to implement server controls for either JavaScript equivalents along with whatever standardized HTML offered in this venue.

We gave up easy to develop n-tiered application development for a range of technologies that in reality didn't really offer anything that we already had. Was it the fault of ASP.NET WebForms that many developers chose to implement massive amounts of code in the web page code-behind modules when most of it should have been placed in tiered libraries?

Certainly with the complexities of ASP.NET MVC and now Core, poor application development was just as much a danger to software quality as the original environment was. But wasn't that supposed to be the choice of the developer?

And what about this nonsense, which everyone touts as "a separation of concerns"? What, developers cannot understand how to do this without a new paradigm to help them along!?

Of course we have the claim that ASP.NET MVC allows for Test Driven development. So what? What type of tests is anyone going to write for a database intensive application where the majority of such work will be the correct updating of data or its retrieval? Developers can no longer understand their own results? Has anyone considered that try-catch blocks are the best way to capture erroneous processes? And what other way would one do so in the event?

In the 1990s a former chemical engineer turned software engineer wrote an excellent manual for developing top performing client-server and web applications. He demonstrated the correct way to create such applications all of which was based on efficient n-tiered architectures with all of his work bench-marked to demonstrate its credibility. To this day, I have not come across a single organization that actually implemented any of this person's constructs.

Lets take a single example from this man's work to demonstrate this. To increase application performance at the very least by 50%, one should divide their database systems to handle both OLTP transactions for updating and OLAP for data retrieval. This way, two sets of database servers (clustered or not) divide divide the work so that the data access type benefits from the most efficient way of processing them.

Too much work (and costs) for organizations to consider was the basic, unstated reason for ignoring such a design.

So the propagandists in our profession decided that manipulating all of the code would be better way to achieve such performance. Well, guess what? Hardware engineers and specialists in the 1990s also demonstrated that this was and still is complete nonsense. Developing high performance web applications is completely reliant on quality hardware that can perform well. No amount of code manipulation will make a web application work better if the underlying hardware is not there to support it. Of course, with bad code one can certainly make a web application perform poorly but with good code, the benefits to speed can only be maximized so much. Remember that the underlying architecture and protocols of the Internet are still the original ones designed in the 1970s.

In 2005 or a little later another book was produced by a Silicon Valley software engineer, entitled, High Performance ASP.NET Applications. This book corroborated the earlier hardware engineer findings by demonstrating that not only was proper hardware necessary for good performance but that its configuration (both hardware and software) was vital as well, which this book showed one how to do.

This book hardly made a ripple on our profession since most such implementations were handled by teams that had little to do with actual software development.

Over the years we have gone from one ridiculous, development paradigm to another, none of which really abided by classic and well researched software engineering standards. Instead it became the tools we used instead of how we actually developed our applications.

Just a few years ago, another software engineer took a medium sized ASP.NET WebForms application and converted it to the ASP.NET MVC environment to understand the performance differences since there has been really very little such research done in our profession (Unfortunately, I have since lost the link to this engineer's findings.) What this engineer found was that there really wasn't a significant difference between a decently written WebForms application and that of an MVC one.

I doubt that with all the latest tools from Microsoft and other third-party vendors this difference has really been greatly changed. Again, it goes back to the hardware for which recent years have seen great strides in the internal workings of the various chip-sets and disk drives.

So why ASP.NET MVC\Core???

Younger generations of developers really do not have the experience to make such comparisons while the older developers, of which there are really few of us left any longer, should have known better.

It seems to me that the real reason for the growth of the MVC paradigm had nothing to do with any significant increase in developer productivity or application performance. How could it be with the massive complexities that have become part and parcel to such development. As a result, this smacks of a foundation for job security more than anything else. The more complex a skill is, the fewer people can master it. And that means fewer quality developers for the hiring.

I mean, who in their right mind would use ASP.NET MVC\Core and then tout its benefits? And for whom by the way? Certainly it is not the corporations who allow its implementation since there isn't a single reason that anyone has espoused that provides for better development efficiency that a corporation could take advantage of. Does one really believe that a few saved milliseconds actually enhances a corporation's operational efficiencies?

In my long career, I have developed just about every type of application there is to develop within the business development environments with the few exceptions of such applications such as trading applications or the like. Nonetheless, using our original tools at the time, I and my fellow colleagues were able to produce high quality software that rarely if ever produced issues for our users.

And yet today, with all the wonders of software, technological advances, many web sites do not operate properly and many are increasingly being breached with huge amounts of critical data being appropriated. Any security specialist could tell you that part of this rampant criminality is the construct of the Cloud but also, simply the inherent complexity of what we use to develop, which provides fertile ground for increased defects and vulnerabilities for our applications.

ASP.NET WebForms may be dead and of course now shunned. However, had the professional development community insisted that Microsoft rectify its flaws, the company would have done so and was doing so until its shunning became too much of a burden for Microsoft to credibly maintain.

I believe that my profession has bet on the wrong horse. And with the stresses and complexities in web development today, it appears that this bad bet is causing us a lot of issues. From dissatisfaction in our work to contending with increasing amounts of defects, it may be time that my colleagues reconsider their decision to support such a cantankerous, development environment. Or maybe too many of you are simply to heavily invested to do so.

Sometimes, returning to the old ways is the best course of action for the future. And with the technological quagmires we have in our lives today, maybe overall simplicity should be the overriding concern for deciding upon a development technology.

Whatever the critics of this piece may say, they simply cannot deride the overall simplicity in development efficiency and the greater compartmentalization of such development that ASP.NET WebForms provided.

Who are you going to listen to; some engineer who is promoting a paradigm, an ideology, or someone who is promoting a tool that just got the job done and done well...

Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com

Mycroft Holmes16-Aug-20 13:53

Mycroft Holmes

16-Aug-20 13:53

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

Steve Naidamast18-Aug-20 7:51

18-Aug-20 7:51

Mycroft...

A fan of the great detective are we? Smile | :)

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

Mycroft Holmes18-Aug-20 13:11

Mycroft Holmes

18-Aug-20 13:11

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 Blush | :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 Naidamast18-Aug-20 13:28

18-Aug-20 13:28

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. Smile | :)

Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com

Richard Deeming16-Aug-20 23:47

Richard Deeming

16-Aug-20 23:47

WebForms may be simpler for simple drag-and-drop development, but the moment you try to do anything sophisticated it gets a lot more complicated.

MVC provides a lot more flexibility, but it does require more familiarity with how web applications work. But having seen some of the common rookie mistakes - using MessageBox.Show, trying to save and launch files directly to the client, trying to read files directly from the client, etc. - that's probably not a bad thing.

All web applications have to use HTML, CSS, and Javascript for their UI. WebForms had a lot of third-party controls which did the dirty work for you, but that comes at the cost of flexibility. There are also third-party UI components for MVC and plain Javascript - they just need a little more setting up than dragging a control from the toolbox onto your page.

If you're still a fan of WebForms, perhaps you might want to look at Razor Pages or Blazor instead.
Introduction to Razor Pages in ASP.NET Core | Microsoft Docs[^]
Blazor | Build client web apps with C# | .NET[^]
Escaping WebForms is a tough gig, Blazor might have the solution[^]

"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer

F-ES Sitecore17-Aug-20 2:10

17-Aug-20 2:10

I can't say I've ever considered performance to be one of the benefits of MVC, however given there is less framework stuff going on under the covers it should perform slightly better and I believe tests have shown that it does.

WebForms was an attempt to being the desktop paradigm of coding to the web where the mechanics of http was hidden behind a framework that supplied a persisted state and event-driven model the way desktop GUI apps work. I suppose this was to help people move from desktop to web easier with less of a learning curve. Conversely MVC is more of a bare-bones framework that requires better understanding of http. I'd also say it is better balanced than webforms where you can make your code server-side only, client-side heavy or a mix of both, where WebForms was focused on making things server-side only and it could be tricky doing things that were client-rich. When WebForms was popular this wasn't an issue but as the web got more client-right WebForms got slightly more unwieldy.

As Richard said, while this was a learning curve for some is it really a bad thing? Shouldn't people commit to understanding web technologies if they are writing web sites? Your remarks that MVC somehow requires javascript is a common misconception I see. You can still write everything server-side and have your partial views function like asp serverside controls if that is what you want, nothing is stopping you, you just have to handle the state management yourself and know how to work out what button was pressed, or if you want a linkbutton or autopostback type feature you'll need some js to replace the js that WebForms created for you automatically. Sure it's more work, there's no doubting that WebForms made certain tasks easier but that ease of use came at an efficiency cost and it was easier to write "bad" WebForms code.

Testing is another tool in the MVC toolbox even if you don't do test-driven development. Properly written MVC applications make it far easier to unit-test more aspects of your code due to the decoupling from a web context. That might not be important for you, but it is important in many big organisations that like to have test coverage.

I think what it really comes down to is that WebForms was seen by many (rightly or wrongly...I personally think wrongly) as a RAD or a "prototyping" technology and moving to the MVC paradigm has allowed it to grow up a little and become a bit more professional, offering greater flexibility at the expense of the developer having to do a little more work and understand web technologies a bit better.

Steve Naidamast18-Aug-20 5:22

18-Aug-20 5:22

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. 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.

JavaScript as a basis for such components was never a wise choice by developers simply because the language was never designed for such usage and according to a recent document discussing the nature of the current JavaScript environments still has not been refined well enough to do so. In reality, this leaves MVC with a very limited basis for its implementation, that of content sites. In fact, until it was taken down from the Microsoft site, this emphasis was in fact promoted by Microsoft until they realized that people were using MVC for more than it was designed for.

Having worked on one of the largest MVC projects in the United States in 2010, I saw first hand how inept this paradigm was for complex database project development. The work required to implement such a basic framework was completely out of line with the requirements and deadlines the project had been based upon as I and my colleagues had to work far harder and longer to accomplish the same things that would have been required by the more sophisticated WebForms construct. The fact that WebForms may have not been as efficient as the MVC environment really made little sense to worry about given the huge complexities dinvolved.

Though my colleagues were highly capable software engineers and I admired them for such capabilities, it made little sense to me why they would put themselves in such a position that required them to work far longer hours with far more complexity than that which would have been required had the project been developed with WebForms.

The reason for all this was that my colleagues were of the opinion that this new MVC paradigm was the correct way to build new Internet applications.

They were abjectly wrong since there is no correct way to build such applications. The Internet is based upon a very old technology that was primarily designed to simply support basic messaging, not the complexities that are being sent over it now. In the end, the Internet's primary request and response methods are still the only two communication factors that are available to us at a general level, with lower level forms of communication being more recently implemented.

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. That job is for network and hardware specialists.

And even if one knows how the Internet works, so what? You are still going to be bound with how any one software tool works to develop your applications.

Recently Microsoft has produced the Blazor environment and the new Razor Pages development paradigm; neither of which appear to work very comfortably considering that attempting to mix the two under certain circumstances yields unworkable conflicts. And yet one has a hard time attempting to figure out just where one environment ends and another picks up based on a lot of the documentation I have gone through.

Razor started off as a more efficient view-engine for MVC and now it is being touted as an alternative development environment on top of the ASP.NET MVC foundation. In fact, Microsoft is touting Razor Pages as the new WebForms. However, trying such an implementation out in its various formats had its own issues demonstrating that it was hardly ready for prime time development. The biggest one I found was the arcane techniques required to extract data when posted from the front-end. I imagine this will be corrected over time but it brings up the question as to why Microsoft would even tout such a development as a new form of a now denigrated technology. I suggest that it is most likely that Microsoft, very late in the game, realized their mistake by dropping the WebForms paradigm in the first place as ASP.NET MVC simply cannot compete with its sophistication and simpler style in the development of quality applications. And for all its inefficiencies, WebForms development, when done correctly, yielded far fewer defects that any other overly complex technology such as MVC would do so under stressful conditions.

In fact, Microsoft did attempt to port WebForms to its new ASP.NET Core environment but found that doing so was causing all sort of issues. As a result, they have been working their way back to it with their latest implemntation of Razor Pages. Nonetheless, the current mechanism in Razor Pages that appears to work consistently is a complete throw-back to Classic ASP, whereby C# code is inherently mixed with HTML markup in a single file. What is this? And now we are supposed to believe that after years of denigrating such a mixture of code it is supposed to be the "new thing"?

There are developments in Razor Pages with a new form of Code-Behind modular structure as was with the WebForms Aspx construct but I have not found it to work very consistently... At least not yet...

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. No one in their right mind would promote such a bare-bones framework as ASP.NET MVC under such circumstances that relies on so many auxiliary technologies to make it work with the complex interfaces involved.

I saw this first hand and ASP.NET MVC has not evolved to a point that would make such implementations easier. In fact, it is getting even more complex than its earlier incarnations. And complexity is the bane of quality software development...

Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com

F-ES Sitecore18-Aug-20 6:14