5 ms·

I'm finishing a survey of web development technologies class. We've covered everything from PHP to Perl + CGI, classic ASP and ASP.NET, and JSP. I spent this

I'm finishing a survey of web development technologies class. We've covered everything from PHP to Perl + CGI, classic ASP and ASP.NET, and JSP. I spent this past summer learning RoR, and I plan on picking up Django next summer. [non-flame-bait personal opinion] And, I have to say that I came to a strong dislike for ASP.net. In fact I was carrying a 4.0 until this ASP.NET project. I disliked it so much, I didn't finish the project. Perhaps if I spent more time on it, It might fit a little better, but from what I"ve seen, I hate it mightily. The benefits: It works well with IIS and the Microsoft Server stack. If that's what you know, stick with it. You'll spend months learning unix shell commands, and file structure, and how to install things, etc... I'm more of a unix guy and prefer to develop with unix on the server side. If that's not your cup of tea, then stay on the Microsoft side of life. The cons: I also didn't like the idea of ASP.NET pages. I found it really combuersone to code all the labels in the body of the <script> tags, and then output them at the bottom in the html. I simply found it really hard to get my mind around the ASP.NET way. I really didn't want to understand the ASP.NET way, I guess. I don't like how it handles SQL queries. I found it burdensome and cumbersome to write 5-6 lines of code on every page that access the database, to set the SQL query to a variable, execute the query. put the SQL query into a reader, then transfer the reader to another variable that's usable. Too long, clanky, too long. And, doing that for every page you're working on: BOORRRIIIINnnnggg! :) Disclaimer I was just starting out with ASP.NET, and I'm sure there's tips and tricks that would speed development up, and I'm sure I went about things all wrong. It's just that Rails really spoiled me this past summer. with the MVC model. Set up database connections once, access what you need through active record. Variables are there for you in the controller. Spit them out and format them in your views. It's like Ron Popeil says about his rotisserie: You set it and forget it! [/non-flame-bait personal opinion]

ubelt 19y ago
iamelgringo, Have you tried Data Access Application Blocks? We use them and we only need 1 line of code to read the database. SqlHelper.ExecuteReader(strConnTxt, CommandType.Text, strSql); Alternatively, you can use SqlHelper.ExecuteDataset. We also use Code Generation software that builds all the CRUD methods automatically.
- mrtron 19y ago
  <cringe>We also use Code Generation software that builds all the CRUD methods automatically.</cringe> I can understand what would bring you to using a code generator, but the examples I have seen in practice are not good. I think code generators show there is something fundamentally wrong with the language/framework.
  - DanielBMarkham 19y ago
    So the use of standard abstractions and conventions in something like a DAL show a lack of what, exactly?
    - mrtron 19y ago
      It shows a lack of nothing. What DAL is a code generator that writes large quantities of code based on your 'models'? It simply provides a better or easier interface. Here is what I meant: When a commercial application becomes popular to generate large amounts of code to do a small amount of work, like some CRUD, I personally feel that shows a flaw in the fundamental way the language works. The language should either be able to offer you a better way of doing it yourself, or writing a small framework for yourself. If neither of these are viable options, I would consider that a serious knock against the language.
      - DanielBMarkham 19y ago
        I'm hoping I'm not getting into a flame war -- not my intent. Here's the problem with what you said -- the word "code". It's not defined. In any kind of large environment, my application uses all kinds of compiled code. So what if I push a button or flick a switch to use another hunk of code that I don't have to write or test? Is using System.Io somehow "better" than say, having an automated macro that generates IO based on some user preference? Yes -- I would agree that if I have to write and maintain a large amount of code to do easy stuff we've got a problem somewhere. But if my platform is powerful enough to allow me to use multiple Data Access paradigms without any work on my part? Who cares if when I flip the switch the code is generated and compiled or if it was generated and compiled last week or last year? Take a look at something like CodeSmith. Here's a tool that uses .NET to write programs for .NET. Now yes, you can generate a lot of code that way -- if you want to look at it like that. You can also go and get open source libraries and templates that will generate tested, proven, full-featured libraries based on your particular situation. Isn't that a much better thing than simply having one paradigm that everybody has to shoe-horn their work into?
DarrenStuart 19y ago
if you use datasets you can do all that boring sql stuff in 1 line of code. Also you can create a DAL and map those objects to the server controls without writing a line of code if you use VS2005 and above. MVC for asp.net is on the way btw.
- deleted 19y ago
  [deleted]
hello_moto 19y ago
You should either use NHibernate, SubSonic or wait for EDM/LinQ in the upcoming ASP.NET so you won't deal with 5-6 lines of ADO.NET code. But I have to agree with you, it's not that straightforward to understand ASP.NET esp if you have previous knowledge of developing web-app because ASP.NET tries to abstract everything out for you (via their Controls, ViewState etc). On the other side, ASP.NET might not be discipline in terms of MVC but then again it is ridiculously easy to re-create a GridView such that I don't care much about the VC part of the MVC. I write less code thanks to Visual Web Developer tool.
- iamelgringo 19y ago
  Wow, thanks, Guys. If I were still working on that project I'd probably pick your brains a bit more. And, I think that you hit the nail on the head about abstracting everything out for me. In the short ammount of time, I just couldn't grokk it, but I knew I didn't like it. It seemed like ASP.NET was a purposefull movement away from typical web development. And, I'm sure that Microsoft was trying to fix problems that they say with typical web dev. I just think that there are better solutions out there than ASP.NET. But, if you're a windows guy and used to coding in Visual Studio, and you can already use the languages that you are used to, it might be a really good idea.
  - hello_moto 19y ago
    Better solution depends largely on how your brain works. Some people brain map better with LISP, some work better with OOP/Java.
  - johnb 19y ago
    I found that ASP.NET was a good stop off point between writing desktop apps and writing web apps. All the event handling logic and the postback thing meant I could bring most of my desktop thinking across and be productive immediately. The problem I had was once I had been working on the web a while I realised the abstractions were broken but the framework didn't leave me anywhere to go.
DanielBMarkham 19y ago
I'll jump into the flames -- what the heck. The problem isn't ASP.NET: it's probably the way you were taught how to use it. The Microsoft tools do so much crap that it's like being put into a room full of levers and knobs with cryptic labels on them. Hard to know where to start or how to make things work. Sit down with somebody who is using one of the automated DALs (like NetTiers, NHibernate, CSLA, etc) and knows what the heck they are doing. You'll find it very intuitive and the speed of development can keep pace (or surpass, depending on the domain) any other kind of web development. Now for the BUT part. BUT you have to be doing straight-forward business development. Stuff in the middle of the road. Writing a check. Checking your email. Posting a message.Viewing your box scores. Etc. If you want something like an animated dancing baby that does different dances depending on your current stock portfolio and can sing out your RSS feeds in different languages, you're back to basics, and all that abstraction is going to get in your way big time. Also, if you want to scale up to 100K users quickly you're going to be learning a lot more about tweaking IIS and ASP.NET than you probably wanted. But for a lot of stuff, it's just fine. Not everybody is writing the next YouTube, and you can't beat the libraries available to you over on the "dark" side.(grin)
- sohail 19y ago
  "Sit down with somebody who is using one of the automated DALs (like NetTiers, NHibernate, CSLA, etc) and knows what the heck they are doing. You'll find it very intuitive and the speed of development can keep pace (or surpass, depending on the domain) any other kind of web development." Oh come on, this applies for ANY tool in ANY domain. This is non-information.
  - DanielBMarkham 19y ago
    Most ASP.NET training sucks. Does that say it any better? It's not a matter of the lanugage or the platform, it's that the instruction and tools are lame. Certainly that isn't true for any platform, is it?
    - sohail 19y ago
      I'm not sure what you're trying to say!

ubelt 19y ago

iamelgringo, Have you tried Data Access Application Blocks? We use them and we only need 1 line of code to read the database. SqlHelper.ExecuteReader(strConnTxt, CommandType.Text, strSql); Alternatively, you can use SqlHelper.ExecuteDataset. We also use Code Generation software that builds all the CRUD methods automatically.

mrtron 19y ago
<cringe>We also use Code Generation software that builds all the CRUD methods automatically.</cringe> I can understand what would bring you to using a code generator, but the examples I have seen in practice are not good. I think code generators show there is something fundamentally wrong with the language/framework.
- DanielBMarkham 19y ago
  So the use of standard abstractions and conventions in something like a DAL show a lack of what, exactly?
  - mrtron 19y ago
    It shows a lack of nothing. What DAL is a code generator that writes large quantities of code based on your 'models'? It simply provides a better or easier interface. Here is what I meant: When a commercial application becomes popular to generate large amounts of code to do a small amount of work, like some CRUD, I personally feel that shows a flaw in the fundamental way the language works. The language should either be able to offer you a better way of doing it yourself, or writing a small framework for yourself. If neither of these are viable options, I would consider that a serious knock against the language.
    - DanielBMarkham 19y ago
      I'm hoping I'm not getting into a flame war -- not my intent. Here's the problem with what you said -- the word "code". It's not defined. In any kind of large environment, my application uses all kinds of compiled code. So what if I push a button or flick a switch to use another hunk of code that I don't have to write or test? Is using System.Io somehow "better" than say, having an automated macro that generates IO based on some user preference? Yes -- I would agree that if I have to write and maintain a large amount of code to do easy stuff we've got a problem somewhere. But if my platform is powerful enough to allow me to use multiple Data Access paradigms without any work on my part? Who cares if when I flip the switch the code is generated and compiled or if it was generated and compiled last week or last year? Take a look at something like CodeSmith. Here's a tool that uses .NET to write programs for .NET. Now yes, you can generate a lot of code that way -- if you want to look at it like that. You can also go and get open source libraries and templates that will generate tested, proven, full-featured libraries based on your particular situation. Isn't that a much better thing than simply having one paradigm that everybody has to shoe-horn their work into?

DarrenStuart 19y ago

if you use datasets you can do all that boring sql stuff in 1 line of code. Also you can create a DAL and map those objects to the server controls without writing a line of code if you use VS2005 and above. MVC for asp.net is on the way btw.

deleted 19y ago
[deleted]

hello_moto 19y ago

You should either use NHibernate, SubSonic or wait for EDM/LinQ in the upcoming ASP.NET so you won't deal with 5-6 lines of ADO.NET code. But I have to agree with you, it's not that straightforward to understand ASP.NET esp if you have previous knowledge of developing web-app because ASP.NET tries to abstract everything out for you (via their Controls, ViewState etc). On the other side, ASP.NET might not be discipline in terms of MVC but then again it is ridiculously easy to re-create a GridView such that I don't care much about the VC part of the MVC. I write less code thanks to Visual Web Developer tool.

iamelgringo 19y ago
Wow, thanks, Guys. If I were still working on that project I'd probably pick your brains a bit more. And, I think that you hit the nail on the head about abstracting everything out for me. In the short ammount of time, I just couldn't grokk it, but I knew I didn't like it. It seemed like ASP.NET was a purposefull movement away from typical web development. And, I'm sure that Microsoft was trying to fix problems that they say with typical web dev. I just think that there are better solutions out there than ASP.NET. But, if you're a windows guy and used to coding in Visual Studio, and you can already use the languages that you are used to, it might be a really good idea.
- hello_moto 19y ago
  Better solution depends largely on how your brain works. Some people brain map better with LISP, some work better with OOP/Java.
- johnb 19y ago
  I found that ASP.NET was a good stop off point between writing desktop apps and writing web apps. All the event handling logic and the postback thing meant I could bring most of my desktop thinking across and be productive immediately. The problem I had was once I had been working on the web a while I realised the abstractions were broken but the framework didn't leave me anywhere to go.

DanielBMarkham 19y ago

I'll jump into the flames -- what the heck. The problem isn't ASP.NET: it's probably the way you were taught how to use it. The Microsoft tools do so much crap that it's like being put into a room full of levers and knobs with cryptic labels on them. Hard to know where to start or how to make things work. Sit down with somebody who is using one of the automated DALs (like NetTiers, NHibernate, CSLA, etc) and knows what the heck they are doing. You'll find it very intuitive and the speed of development can keep pace (or surpass, depending on the domain) any other kind of web development. Now for the BUT part. BUT you have to be doing straight-forward business development. Stuff in the middle of the road. Writing a check. Checking your email. Posting a message.Viewing your box scores. Etc. If you want something like an animated dancing baby that does different dances depending on your current stock portfolio and can sing out your RSS feeds in different languages, you're back to basics, and all that abstraction is going to get in your way big time. Also, if you want to scale up to 100K users quickly you're going to be learning a lot more about tweaking IIS and ASP.NET than you probably wanted. But for a lot of stuff, it's just fine. Not everybody is writing the next YouTube, and you can't beat the libraries available to you over on the "dark" side.(grin)

sohail 19y ago
"Sit down with somebody who is using one of the automated DALs (like NetTiers, NHibernate, CSLA, etc) and knows what the heck they are doing. You'll find it very intuitive and the speed of development can keep pace (or surpass, depending on the domain) any other kind of web development." Oh come on, this applies for ANY tool in ANY domain. This is non-information.
- DanielBMarkham 19y ago
  Most ASP.NET training sucks. Does that say it any better? It's not a matter of the lanugage or the platform, it's that the instruction and tools are lame. Certainly that isn't true for any platform, is it?
  - sohail 19y ago
    I'm not sure what you're trying to say!