Designing Your Application

When designing an application, there are two possible main routes. The first is the procedural approach (anyone familiar with ASP 3.0 and earlier who did not use COM objects to handle logic knows exactly what I mean): the simple "Pagel" does this,"Page2" does this, and so on.You have a set of "top-down" ASP scripts (that is, your code starts at the top and executes until it hits the bottom), with functions including files, which make up your application.There is technically nothing wrong with this approach, as there are many large-scale applications that are written exactly this way.

Figure 13.7 The SQL Server Diagram

Figure 13.7 The SQL Server Diagram

Your other choice is to take a more Object-Oriented (OO) approach. In an OO world, you create a set of classes and interfaces that make up the core of your application. Using these classes, you create a user interface that will define what an average user would consider your "application."This approach allows the designer of the classes to encapsulate a good majority of all the code and logic behind the application, without exposing it to whomever might be building the user interface (and likely, the same person will be building both). An OO approach also allows your application to be used in a variety of ways, and would allow someone to build multiple user interfaces on top of the exact same set of classes.

Both approaches have their merits and flaws.With the procedural approach, you will be stuck in ASP.NET for your user interface, and if you want to "copy" logic from one place to another, you either have to create globally scoped functions, or copy and paste code.The procedural approach does tend to be a bit easier to create, though, because you do not have the additional overhead of having to create classes to handle your logic and data. The Object-Oriented approach effectively encapsulates your entire application into a small set of classes, grouped into an assembly .dll file, which can be created from another application and used. This allows you to hand another developer your assembly file, and let him or her go about building the actual user interface without you ever needing to know what the user interface was. The drawback to building an application in an OO-manner is whomever is developing the classes needs to take a lot of care to get it done properly, and be able to build it in such a manner as to not tie it exclusively to one type of user interface.

When deciding whether or not dotBoard should be procedural or Object-Oriented, take into account these things. First and foremost, you need to be able to maintain your code. If your code is modularized into multiple functions and organized very well, then the procedural approach doesn't seem too bad. However, if your code is placed haphazardly throughout your application, finding your bugs and improving code at a later date might be harder. If your code is organized into a set of classes and public interfaces (the methods and procedures that an application can "see"), it is typically easier to maintain your code, as each piece of each class is a very small piece of the application as a whole, and making changes won't likely take a large amount of code.

The other thing you should think about is that dotBoard is being written in VB.NET. For anyone who has built an application in straight ASP, you would probably be more comfortable with the procedural approach. For anyone who has built an application in ASP and created VB COM objects, you would most likely be more comfortable with the Object-Oriented approach, but feel some trepidation about speed and performance issues. For the master gurus out there who are building C++ ATL COM objects and using them in ASP, you might scoff at VB.NET and think you would rather stick with C++ ATL COM.Well, all of you have very valid points. A straight procedural approach is generally looked down upon in a professional environment,VB COM objects in ASP are typically regarded as slow and frequently memory- and processor-intensive, and well, nobody can read the C++ ATL code anyway, so it doesn't count!

Seriously, though, every point made is very valid about every technology dis-cussed.That's where VB.NET comes in.The .NET runtime is remarkably fast. The Just-In-Time (JIT) compilation of your code only happens the first time it is executed; so, after that initial execution, your code runs incredibly fast until you change it (at which point the JIT compilation happens again).VB.NET is also a fully Object-Oriented language. It provides developers with every good OO technique available, and it is actually quite easy to write OO applications with it.

All that said, it's pretty obvious dotBoard should be an Object-Oriented application. Don't worry if you've never written any OO code before. Object-Oriented techniques are relatively easy to implement, and even if you don't think you've ever used any objects before, you probably have (especially if you've done any development in ASP).

0 0

Post a comment