Need advice on .NET
-
I have a new job and they are a Microsoft shop (SQL Server, IIS, etc).
I'm not new to programming, but I'm new to .NET. My background is LAMP (about 5 years), with a smattering of Java (about 2 years) and ASP/VBScript (about 6 months). I've generally avoided Microsoft 'solutions' because of the PITA that I regularly encountered with simple things like file uploads during my short stint with ASP/VBScript.
Anyway, .NET appears to be a pretty powerful framework for web applications and, quite frankly, I don't have much of a choice but to adopt since the company I work for is moving in that direction.
At first, I tried out phalanger (the php compiler for .NET) so that I could stick with PHP yet still be able to use .NET. However, I quickly discovered that my company won't allow us to diverge from whatever comes out-of-the-box with Win2k3 server.
Anyway, I'm seeking advice on the best route to take for getting my feet wet. I have access to books24x7.com, so I should be able to read just about any book you recommend. It appears as if C# is the best route, but Visual Basic .NET (at the 50,000 ft level) seems like it would be a faster transition into the whole .NET concept. What worries me is that we'll be eventually building fairly large apps that have to be pretty scalable, so I don't want to move forward with something that won't deliver. Essentially, I'm hoping that whatever language I use will lend itself to good web design with the ability to effectively use the MVC model.
I attempted to read a 'weekend crash course' book that was supposed to introduce .NET in three days. I stopped reading when the sample code violated every aspect of good programming that I've come to appreciate (poorly written HTML, bad coding standards, etc). I was also turned off by these <font face="Courier New">runat="server"</font> attributes all over the place. It seemed like there was a reliance on the .NET engine to write the code for me for things like form fields and such...very "Save as HTML" feel to it that I didn't like at all. I quite possibly chose the wrong book, but you never know.
If someone wouldn't mind shedding some light for me on the best route to take, it would be greatly appreciated!
TIA,
Jon
-
Gee, I should have taken a little more time reading the forum before I made this post. I've found many answers in this thread and the URLs listed in many of the responses:
Sorry for cluttering up the forum with a repeated question (I was in a hurry, sorry)
-
You can read all about the C# vs VB thing just about everywhere. Suffice it to say that my personal pref is strongly C#. VB works finem but reading that syntax is just awful.
Books: I can recommend the O'Reilly line. Jesse Liberty's C# books are great to get up to speed with the language. The ASP.Net book by Liberty & Hurwitz was good, but they don't seen to have the 2.0 edition out yet. I haven't read the Nutshell book yet, but it's probably pretty good.
As far as using ASP.Net itself, that takes a little time. You'll need to change your mindset a bit. Try not to think of it as a "web" app so much and focus on the OO aspect of the app in its entirety. The .Net way seems to be less about the UI and more about code reuse. Go ahead and let the server gen the markup for you; don't fight it. The good news is that 2.0 gens XHTML (1.1 was just HTML 4). We use CSS extensively, and ASP.Net plays well with it for the most part. If you're into it, check out the Atlas AJAX library.
For our ASP.Net apps, we try to keep the actual web project slim; we put almost all the biz logic in separate assemblies (also C#). This greatly helps the dev process and the release process.
HTH
-
@John Smallberries said:
The .Net way seems to be less about the UI and more about code reuse.
But you still have "plain" .aspx files that form the foundation of your site, just like in classic ASP. Files that are parsed by the server and what's left gets sent to the browser. You got your includes and your DLLs.
How much of a paradigm shift are we talking about, really?
By the way, I'm an ASPclassic/JScript developer, but a transition to .Net is in the future.
-
@dhromed said:
@John Smallberries said:
The .Net way seems to be less about the UI and more about code reuse.
But you still have "plain" .aspx files that form the foundation of your site, just like in classic ASP. Files that are parsed by the server and what's left gets sent to the browser. You got your includes and your DLLs.
How much of a paradigm shift are we talking about, really?
By the way, I'm an ASPclassic/JScript developer, but a transition to .Net is in the future.
ASP.NET is completely, 100% different from ASP in every way except for the fact that you can write things the "old way" in ASP using scripting tags embedded in your aspx files. And that would just be silly.
Server controls, compiled code, the .net framework, post backs, data binding, templates, server-side events -- it's a huge shift moving to ASP.NET from ASP.
-
@Jeff S said:
@dhromed said:
@John Smallberries said:
The .Net way seems to be less about the UI and more about code reuse.
But you still have "plain" .aspx files that form the foundation of your site, just like in classic ASP. Files that are parsed by the server and what's left gets sent to the browser. You got your includes and your DLLs.
How much of a paradigm shift are we talking about, really?
By the way, I'm an ASPclassic/JScript developer, but a transition to .Net is in the future.
ASP.NET is completely, 100% different from ASP in every way except for the fact that you *can* write things the "old way" in ASP using scripting tags embedded in your aspx files. And that would just be silly.
Server controls, compiled code, the .net framework, post backs, data binding, templates, server-side events -- it's a *huge* shift moving to ASP.NET from ASP.Bah! Code behind is for weenies. Give me one giant main any day. And mixed markup with script. Lots of it. And script that dynamically generates javascript that generates html that loads xml islands populated with data from other asp pages that take querystring values as arguments to stored procedures that use dynamic sql to output xml documents and style sheets, which, when transformed produce runnable javascript that generates html...
-
@Oscar L said:
Bah! Code behind is for weenies. Give me one giant main any day. And mixed markup with script. Lots of it. And script that dynamically generates javascript that generates html that loads xml islands populated with data from other asp pages that take querystring values as arguments to stored procedures that use dynamic sql to output xml documents and style sheets, which, when transformed produce runnable javascript that generates html...
The Real WTF<FONT size=1>(tm)</FONT> is that you aren't planning on using Excel macros anywhere - you can't do anything without Excel macros!
-
@Oscar L said:
Bah! Code behind is for weenies. Give me one giant main any day. And mixed markup with script. Lots of it. And script that dynamically generates javascript that generates html that loads xml islands populated with data from other asp pages that take querystring values as arguments to stored procedures that use dynamic sql to output xml documents and style sheets, which, when transformed produce runnable javascript that generates html...
I see you've worked on projects with me before...
Ok, I'm joking. I do prefer code-behind [what I've used of it] to old ASP-style mixed markup, but I tend to prefer clean mixed template-based systems [like, perl's Template Toolkit and Maypole] to code-behind as the complexity of the interface increases. I get components [.NET style, preferred], and an easy-to-use minilanguage. If I'm doing something really hackish, I can still inline perl, too.
I know I can achieve the same effect in .NET (first thing I figured
out, then realized there was a better way to do what I wanted), but it
felt a bit weird. [I derived a new page class....]
Also, if I'm generating non-html [think Excel], or doing something with the HTML other than sending it directly to a browser, I prefer the perl approaches. For database->page, though, C# is absurdly powerful, out of the box. If I were working on larger web-projects, [and I were not simply more comfortable with other languages] I'd probably use it more often. Most of it seems really neat.
-
@John Smallberries said:
As far as using ASP.Net itself, that takes a little time. You'll need to change your mindset a bit. Try not to think of it as a "web" app so much and focus on the OO aspect of the app in its entirety. The .Net way seems to be less about the UI and more about code reuse. Go ahead and let the server gen the markup for you; don't fight it. The good news is that 2.0 gens XHTML (1.1 was just HTML 4). We use CSS extensively, and ASP.Net plays well with it for the most part. If you're into it, check out the Atlas AJAX library.
HTH
You've helped a great deal! I'm still a little wary of 'auto generated' HTML code. Having used template systems in an MVC model, it's a tough sell to get me to give up that coding style.
I've started reading about this "Master Page" concept, but it seems clunky...is that the way to go to achieve a true MVC model or would I be better off harnessing the XML prowess of .NET and using XSLT instead?
Obviously, I've got more reading to do, but has anyone else achieved a MVC model with .NET (regardless of language)?
I'm also going to check into Atlas...AJAX is definitely part of the design process now that my company has stopped supporting 4.x browsers.
Thanks!
Jon
-
@John Smallberries said:
Go ahead and let the server gen the markup for you; don't fight it. The good news is that 2.0 gens XHTML (1.1 was just HTML 4).
Doesn't matter at all, good XHTML 1.1 is functionaly equivalent to good HTML 4.01, and is also handled as such when served as text/html (which it usually is, and I highly doubt that ASP.Net handles content negociation out of the box).
ASP.Net generated bad HTML 4.01 and it now generates bad XHTML 1.1, that's wankery.
