3 ms·

I don't 'get it': I'm developing a Web site, my first serious one, and using the standard Microsoft software tools Windows, IIS, Visual Basic .NET, ASP.NET, A

by graycat 13y ago

I don't 'get it': I'm developing a Web site, my first serious one, and using the standard Microsoft software tools Windows, IIS, Visual Basic .NET, ASP.NET, ADO.NET, SQL Server, and some of the rest of .NET, e.g., TCP/IP sockets. For entering the code, I am using my favorite (programmable) text editor and believe it is working very well. Otherwise I use some scripts I've written in my favorite scripting language. To do this development I read through about a cubic foot of books and 4000+ Web pages of documentation, nearly all from Microsoft's Web site. For the development I struggle some with 'scope of properties' in CSS (which apparently is nearly never discussed) and much of the documentation, but otherwise from the server farm architecture to the computing to be done down to the lines of code and documentation, there are no problems. E.g., for a single Web page, say, X, there is a file X.ASPX, and it has some options, some static HTML and CSS, some 'event handlers', e.g., Sub Page_Init Sub Page_Load Sub Page_PreRender Sub Page_Unload some Visual Basic code, a lot of use of classes from ASP.NET, ADO.NET, etc., and some include files for CSS, functions, classes, etc. Fine. And I don't have even as much as a weak little hollow hint of a tiny clue what MVC is or why I should want or need it. The explanations of just why I should want MVC look to me as burdensome and totally meaningless distinctions and constructions for no good reason. Same for a 'framework'. Same for Nancy and everything else in the OP. E.g., the OP talks about GET and POST "methods". I don't do those things -- IIS and ASP.NET handle those for me. If I want the actual post data, then it's available to me via some ASP.NET classes. But the code I write doesn't deal very directly with GET or POST. And have I found no good explanation of why I shouldn't just continue as I am. I don't have a clue what OP is talking about. My guess is that MVC, Nancy, etc. are for programmers with backgrounds in Web development on Linux who want to program on Windows and there use programming tools and techniques they used on Linux instead of just the usual Windows IIS, ASP.NET, etc. I've already read a cubic foot of books and 4000+ Web pages of documentation, and my work is going fine; why should I junk my work to date, read a lot more documentation, involve myself in more overhead of tools instead of just going my real work? More documentation can have errors; more tools can take me farther from the real data and can have bugs. Am I doing something seriously wrong?

untog 13y ago
E.g., the OP talks about GET and POST "methods". I don't do those things -- IIS and ASP.NET handle those for me. You might be absolutely fine not knowing those things, but at some point down the road you are going to be lacking some essential knowledge of how HTTP works. To put it simply: everything - Ruby, PHP, ASP.NET, you name it - uses GET and POST requests underneath it all. Learning about them would be of great benefit to you in the long term. A slightly inaccurate analogy: you can make a perfectly functional web site with Dreamweaver, and not touch a single HTML tag. It'll work fine, until it doesn't, and then you're going to be in a lot of trouble. Given that you don't know what's going on underneath Dreamweaver's GUI, your only option will be to keep hitting 'undo' until it works again. Same for a 'framework'. Same for Nancy and everything else in the OP. ASP.NET WebForms is a 'framework', too. They're just different frameworks. WebForms, as the name suggests, is particularly good at creating forms- it has numerous abstractions to help you maintain state. It's great for intranet data gathering/presentation stuff. But the pages are very, very heavy, loaded down with code that never gets used. So it has pluses and minuses. Just like MVC and Nancy.
- SideburnsOfDoom 13y ago
  ASP.NET WebForms is absolutely a framework and a heavyweight one. It tries to hide the details of http and html as the grandparent says. I for one don't care for that, I prefer a lighter weight framework which works with http rather than hiding it. ASP MVC is lighter weight than webforms, and Nancy or ServiceStack is even lighter weight. Some things like making an endpoint that servces json and xml responses is almost trivial on Nancy or ServiceStack, easy in ASP MVC with WebApi, and a pain in webforms.
  - graycat 13y ago
    Thanks. As I wrote above, as far as I know, I'm not using WebForms and am just using basic IIS and ASP.NET. From what I understand, what I'm using is lighter weight than MVC or anything else being discussed here. So far, I see no problems with what I'm doing. E.g., for the MVC architecture, I have a server farm and software architecture, and it's simple and more than enough.

by graycat 13y ago

untog 13y ago

E.g., the OP talks about GET and POST "methods". I don't do those things -- IIS and ASP.NET handle those for me. You might be absolutely fine not knowing those things, but at some point down the road you are going to be lacking some essential knowledge of how HTTP works. To put it simply: everything - Ruby, PHP, ASP.NET, you name it - uses GET and POST requests underneath it all. Learning about them would be of great benefit to you in the long term. A slightly inaccurate analogy: you can make a perfectly functional web site with Dreamweaver, and not touch a single HTML tag. It'll work fine, until it doesn't, and then you're going to be in a lot of trouble. Given that you don't know what's going on underneath Dreamweaver's GUI, your only option will be to keep hitting 'undo' until it works again. Same for a 'framework'. Same for Nancy and everything else in the OP. ASP.NET WebForms is a 'framework', too. They're just different frameworks. WebForms, as the name suggests, is particularly good at creating forms- it has numerous abstractions to help you maintain state. It's great for intranet data gathering/presentation stuff. But the pages are very, very heavy, loaded down with code that never gets used. So it has pluses and minuses. Just like MVC and Nancy.

SideburnsOfDoom 13y ago
ASP.NET WebForms is absolutely a framework and a heavyweight one. It tries to hide the details of http and html as the grandparent says. I for one don't care for that, I prefer a lighter weight framework which works with http rather than hiding it. ASP MVC is lighter weight than webforms, and Nancy or ServiceStack is even lighter weight. Some things like making an endpoint that servces json and xml responses is almost trivial on Nancy or ServiceStack, easy in ASP MVC with WebApi, and a pain in webforms.
- graycat 13y ago
  Thanks. As I wrote above, as far as I know, I'm not using WebForms and am just using basic IIS and ASP.NET. From what I understand, what I'm using is lighter weight than MVC or anything else being discussed here. So far, I see no problems with what I'm doing. E.g., for the MVC architecture, I have a server farm and software architecture, and it's simple and more than enough.