Conclusion

Decisions about how an application is to be partitioned are never easy, and the Web doesn't change that. On the server side, ASP.NET makes language choice irrelevant. You can use Visual Basic .NET, C#, or any of the third-party languages that are becoming available for the .NET Framework. Of course, even here you do have to be aware of certain language differences, but for the most part, you can just work with the language you prefer.

The client side is quite a bit more constrained. On the client, your only cross-browser-compatible language choice is JavaScript. There's nothing wrong with JavaScript, but this remains the one area in which you don't have a real choice. Add to this the lack of control you have over the state of the client's JavaScript execution environment, and you can see that moving too much data processing to the client isn't a good idea.

Still, there's a place for client-side scripting. Especially on a busy Internet site, performing initial validation and some minor processing on the client side can make the user's experience with the application more immediate, while reducing the load on the server. This can't be a bad thing.

Most compelling Internet and intranet applications have, at their heart, access to dynamic content derived from various databases. In Chapter 8, we'll begin to gather the information you'll need to build such applications. ADO.NET is used to get the data within an aSp.NET application. Don't let the name confuse you: ADO.NET is really more like a distant cousin to ActiveX Data Objects (ADO) than a chip off the old block. Knowing how to take advantage of the changes in ADO.NET can mean the difference between designing a good application and designing a good application that performs and scales well.

Was this article helpful?

0 0

Post a comment