Expert C# 2008 Business Objects

CHAPTER 3 Object-Oriented Application Design (S. 101-102)

Chapters 1 and 2 discussed the concepts behind distributed, object-oriented systems and the .NET technologies that make them practical to implement with reasonable effort. They also introduced the concepts and goals for the CSLA .NET framework. Before getting into the implementation details of the CSLA .NET framework, I think it is important to discuss the object-oriented design philosophy the framework is intended to support, and this is the focus of this chapter.

Chapters 4 and 5 will give you a quick preview of the types of business objects you’ll be able to create with the framework. Being aware of the OO design philosophy and types of objects the framework is intended to help you create will make Chapters 6 through 16 easier to digest. While it is possible to discuss OO design purely in theoretical terms, I find that most people understand it best in the context of a more concrete example.

This chapter will cover a little theory, but will primarily focus on the object-oriented application design process, using a sample scenario and application that will be implemented in Chapters 17 through 21. The design process in this chapter will result in a design for the business objects and for an underlying database. Obviously, the challenge faced in designing and building a sample application in a book like this is that the application must be small enough to fit into the space available, yet be complex enough to illustrate the key features I want to cover. To start with, here’s a list of the key features that I want to focus on:

• Creation of a business object
• Implementation of business validation rules
• Implementation of business authorization rules
• Transactional and nontransactional data access
• Parent-child relationships between objects
• Many-to-many relationships between objects
• Use of name/value lists
• Use of custom CSLA .NET authentication

In this chapter, I’ll focus on the design of the application by using some example user scenarios, which are generally referred to as use cases. Based on those use cases, I’ll develop a list of potential business objects and relationships. I’ll refine this information to develop a class design for the application. Based on the scenarios and object model, I’ll design a relational database to store the data.

As I mentioned in Chapter 2, object-oriented design and relational design aren’t the same process, and you’ll see in this case how they result in two different models. To resolve these models, the business objects will include ORM when they are implemented in Chapters 17 and 18. This ORM code will reside in a specific data access assembly (project), created using LINQ to SQL. The business objects will invoke that data access code to retrieve and update the objects’ data.

This chapter will not focus on the data access mechanism, instead, it will leave those details for Chapter 18. Responsibility-Driven Design Object-oriented design has been around for many years. Unfortunately, there is no unified approach to doing OO design, and this often leads to confusion. Just because someone says he’s doing OO design doesn’t necessarily mean he’s following a similar process to another person who also says he’s doing OO design. Many people want to use objects primarily so they can use dot notation to get at their database. They want to write code like this: int qty = Customer[9].Order[4].LineItem[11].

Product.Inventory.Quantity, Each “object” here is actually some table or data entity that is hopefully loaded automatically and efficiently when it is used. The dot-notation motivation for using objects is not a bad one, but it is not what most people consider object-oriented. Use-Case or Story-Based Analysis Ideally, your objects exist to serve the needs of a specific use case, or user story, or user scenario. In many cases, this means that the objects exist to provide the required business logic and data for each form the user will use to complete a task. That user task is the use case. Following this approach first means that you need to identify the use cases for your application.

This is an analysis process where you interview the business stakeholders and end users of the application to identify the specific tasks that the application must accomplish for the users. Each task is a use case. Of course, some tasks are big and some are small. If a task is big and complex, you might need to subdivide it into a set of smaller tasks, each of which is a use case. This means that some use cases may rely on, or interact with, other use cases.