The Role of C# in the .NET Enterprise
Architecture
C# requires the presence of the .NET runtime,
and it will probably be a few years before most clients -
particularly most home computers - have .NET installed. In the
meantime, installing a C# application is likely to mean also
installing the .NET redistributable components. Because of that, it
is likely that we will see many C# applications first in the
enterprise environment. Indeed, C# arguably presents an outstanding
opportunity for organizations that are interested in building
robust, n-tiered client-server
applications.
When combined with ADO.NET, C# has the ability to
access quickly and generically data stores such as SQL Server and
Oracle databases. The returned datasets can easily be manipulated
using the ADO.NET object model, and automatically render as XML for
transport across an office intranet.
Once a database schema has been established for a
new project, C# presents an excellent medium for implementing a
layer of data access objects, each of which could provide
insertion, updates, and deletion access to a different database
table.
Because it’s the first component-based C language,
C# is a great language for implementing a business object tier,
too. It encapsulates the messy plumbing for intercomponent
communication, leaving developers free to focus on gluing their
data access objects together in methods that accurately enforce
their organizations’ business rules. Moreover, with attributes, C#
business objects can be outfitted for method-level security checks,
object pooling, and JIT activation supplied by COM+ Services.
Furthermore, .NET ships with utility programs that allow your new
.NET business objects to interface with legacy COM components.
To create an enterprise application with C#, you
create a Class Library project for the data access objects and
another for the business objects. While developing, you can use
Console projects to test the methods on your classes. Fans of
extreme programming can build Console projects that can be executed
automatically from batch files to unit test that working code has
not been broken.
On a related note, C# and .NET will probably
influence the way you physically package your reusable classes. In
the past, many developers crammed a multitude of classes into a
single physical component because this arrangement made deployment
a lot easier; if there was a versioning problem, you knew just
where to look. Because deploying .NET enterprise components
involves simply copying files into directories, developers can now
package their classes into more logical, discrete components
without encountering “DLL Hell.â€
Last, but not least, ASP.NET pages coded in C#
constitute an excellent medium for user interfaces. Because ASP.NET
pages compile, they execute quickly. Because they can be debugged
in the Visual Studio 2009 IDE, they are robust. Because they
support full-scale language features such as early binding,
inheritance, and modularization, ASP.NET pages coded in C# are tidy
and easily maintained.
Seasoned developers acquire a healthy skepticism
about strongly hyped new technologies and languages and are
reluctant to utilize new platforms simply because they are urged
to. If you’re an enterprise developer in an IT department, though,
or if you provide application services across the World Wide Web,
let us assure you that C# and .NET offer at least four solid
benefits, even if some of the more exotic features like XML Web
services and server-side controls don’t pan out:
-
Component conflicts will become infrequent
and deployment is easier, because different versions of the same
component can run side by side on the same machine without
conflicting.
-
Your ASP.NET code won’t look like spaghetti
code.
-
You can leverage a lot of the functionality
in the .NET base classes.
-
For applications requiring a Windows Forms
user interface, C# makes it very easy to write this kind of
application.
Windows Forms have to some extent been
downplayed in the past year due to the advent of Web Forms and
Internet-based applications. However, if you or your colleagues
lack expertise in JavaScript, ASP, or related technologies, Windows
Forms are still a viable option for creating a user interface with
speed and ease. Just remember to factor your code so that the user
interface logic is separate from the business logic and the data
access code. Doing so will allow you to migrate your application to
the browser at some point in the future if you need to do so. Also,
it is likely that Windows Forms will remain the dominant user
interface for applications for use in homes and small businesses
for a long time to come. In addition to this, the new smart client
features of Windows Forms (the ability to easily work in an
online/offline mode) will bring a new round of exciting
applications.