Browse DevX
Sign up for e-mail newsletters from DevX


The Baker's Dozen: 13 Productivity Tips for Building a .NET Distributed Application : Page 2

The Common Ground Framework for .NET provides a set of starter classes for building database applications in a distributed environment.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

Tip 2: Building a Login Form
You must present users with a sign-on screen to prompt for a user ID and password. You must also allow the user to specify which database to use—a company production database, a test database, and so on. In addition, the sign-on screen must allow the user to select how they'll connect—the user may be running from a hotel room or other external location where they'll connect through Web services, or perhaps from inside corporate headquarters where the client piece will access the middle-tier and back-end via remoting.
Figure 2: A login form class that prompts for user ID, password, and connection.
Figure 2 displays a sign-on screen from the CGS.Winforms.FrmLogin class. The screen is a generic form that prompts for a user ID and password. The form binds these controls to the static properties found in CGS.Globals. Static properties allow a developer to set properties to specific values and read them later in the application.

The login form also shows a list of available connections by reading the entries in the local XML file CONNECT.XML (see Listing 1). Note that the pulldown contains various options for connecting, either from outside or inside headquarters, and which database to use. The connection class in Tip 4 explains how the application uses the specific contents of this XML file to make the appropriate connection. The Masonry application creates an inherited form from the CG base login form (Masonry.Client.Winforms, as FrmMasonrytLogin). The base form contains several virtual methods that a developer can override—the most critical is the Boolean function ValidateUserID, which returns a true or false based on the implemented authentication rule. Again, Tip 4 will cover this in detail.

Tip 3: Using Interfaces to Define the Back-End Components for Web Services and Remoting
Suppose you've already defined a back-end user business object to perform basic validation of a user ID/password, and a back-end user data object to validate against a back-end database. Now you must construct a Web service and a remoting service for remote clients to execute these functions. Finally, you must also define an interface for the client piece to access either service.

The client piece communicates with back-end functionality by means of interfaces. Interfaces guarantee that when a connection is made, classes will contain specific properties and methods.
The first step is to identify all function points where the client piece will interact (interface) with the back-end. In the case of the sign-on screen, the ValidateUserID function in the login form must call a back-end function with the same name. It will pass the User ID, password, and database key corresponding to the selected database. The back-end will return an XML string with the user's full name and application status.

Both the client and server pieces will use this interface (see Listing 2). Although the client piece will not have design-time access to the actual back-end ValidateUserID function, the interface guarantees that classes implementing the interface will contain certain methods. This also allows the developer to develop for specific interfaces. The second step is to define and develop the business object for ValidateUserID (see Listing 3), which resides in Masonry.Server.BusinessObjects. Note four key items in Listing 3.

  • The user business object implements the IUserObject interface.
  • The user business object inherits from the CG base business object.
  • The base business object in Listing 4 inherits from MarshalByRefObject, from the System namespace. Classes that support remoting must inherit from MarshalByRefObject in order to provide access across application domain boundaries.
  • Finally, the business object references a data access layer that Tip 5 will cover.
After building the business object and making it "remoting-friendly," the third step is to define both a Web service and remoting service to manage client Web/remoting requests. You can easily create a Web service in VS.NET. Assuming you have IIS running, you can create a new project as an ASP.NET Web service, and then add as many different Web services as needed. The demo project utilizes one Web service per business object. Each Web service is named after the corresponding business object, with a 'w' prefix (for example, wUserObject, wInvoice, and so on). In many instances, the Web service function is a basic wrapper for the client piece to access the desired business object. Listing 5 shows the Web service for the user object. Note that the Web service implements the IUserObject interface.

The client piece will access the Web service by creating a proxy for this service, and specifying the actual URL. I'll cover this in more detail in Tip 4. You have to work more to create a remoting server because VS.NET does not offer a project template for remoting. Listing 6 shows a basic remoting server.

Setting up a remoting server requires a few steps. Because the client piece will access the remoting server through a TCP port, you must open and register a TCP channel for that port. The example has port number 8228 hard-coded—you may wish to read that entry out of a configuration file on the server. Finally, you need to register the business object to which the client piece will remote. The application uses a simple Windows Form application to launch the remoting server. In a real-world situation, you'll want to define this as a Windows service that automatically launches when the server boots up.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date