CH APT ER 3 O BJECT -O RIEN TED A PPLI CA TI O N D ESI GN in Visual C#.NET

Create PDF417 in Visual C#.NET CH APT ER 3 O BJECT -O RIEN TED A PPLI CA TI O N D ESI GN

Figure 3-26. Database diagram for the Security database In the Users table, Username and Password are both varchar(20) columns, as is the Role column in the Roles table. Only the Password column allows null values. All other values are required. Of course, a password should be required as well, but for this simple example, it is left as optional. Finally, there s a Login stored procedure. CREATE PROCEDURE Login ( @user varchar(20), @pw varchar(20) ) AS SELECT Username FROM Users WHERE Username=@user AND Password=@pw; SELECT R.Role FROM Users AS U INNER JOIN Roles AS R ON R.UserName = U.UserName WHERE U.Username = @user and U.Password = @pw RETURN PTIdentity calls this procedure to authenticate the user and retrieve the user s list of roles. As you ll see in 17, PTIdentity determines whether the user s credentials are valid or not by finding out whether any data is returned from this stored procedure. If no data is returned, then the user s credentials are assumed to be invalid and the user is not authenticated. On the other hand, if the stored procedure does return data, then PTIdentity stores that data, especially the list of roles to which the user belongs. This list of security roles (not to be confused with the project roles from the PTracker database) is then used for authorization throughout the application. The CanReadProperty() and CanWriteProperty() methods on each business object rely on this data.

This chapter has started the process of building a sample application that will make use of the CSLA .NET framework. It s a simple project-tracking application that maintains a list of projects and a list of resources, and allows the resources to be assigned to the projects. The application s design used an object-oriented analysis technique that involved creating use cases that described the various ways in which the users need to interact with the system. Based on the use cases, and by using elements of CRC-style design, a list of potential business objects was created and refined.

That object list was then used to create a preliminary class diagram that showed the classes, their key data fields, and their relationships. Based on the diagram, our understanding of the business domain, and the use cases, we were able to refine the design to arrive at a final class diagram that describes the business classes that will make up the application. The next step was to determine the appropriate CSLA .NET base classes from which each business object should inherit. The editable business objects inherit from BusinessBase, and the collections of editable child objects inherit from BusinessListBase. The lists of read-only data inherit from ReadOnlyListBase, each of which contain simple child objects that don t inherit from a CSLA .NET base class at all. The list of simple name/value role data inherits from NameValueListBase. Finally, a simple relational database was created to store the data for the application. In most applications, the database already exists, but in this case, we had the luxury of creating a database from scratch. Even so, it s interesting to note the differences between the object model and the relational model, thus highlighting the fact that a good object-oriented model and a good relational model are almost never the same. s 4 and 5 will discuss the basic structure of each type of business object directly supported by CSLA .NET. These chapters will also walk through a code template for each type. Later in the book, after walking through the implementation of CSLA .NET itself, s 17 and 18 will implement the business objects designed in this chapter. 19 will show how to build a WPF UI based on those objects. In 20, a comparable Web Forms UI will be built, and 21 will walk through the construction of a WCF service interface that reuses the exact same objects.