Conclusion

In this chapter, we've walked through the process of creating a basic Windows Forms UI based on our business objects. Obviously, there are many ways to create a UI using Windows Forms, and this particular implementation isn't the only one in which our objects will come in useful.

Because of the way we designed our objects to support nested BeginEdit() calls, we can support very sophisticated user experiences based on nested child windows, or a simpler experience like the one we've implemented here. Since we support full data binding from our objects and collections, we can use the DataGrid control to edit objects or child objects if we need to. The possibilities are very broad.

The key point to take from this chapter is that when we use the business objects, the UI developer doesn't need to worry about business rules, data access, or most other complex issues. The UI developer can focus on the UI itself, the user experience, the look and feel of the application, and so forth. We achieve a high degree of separation between the logical UI tier and the logical business tier through the use of objects in this manner.

At the same time, because the objects use the DataPortal mechanism to retrieve and update data, we have good separation between the logical business tier and the logical data-access tier. Better still, we can simply change the application configuration file to switch between various physical n-tier configurations as needed to meet our performance, scalability, reliability, and security requirements.

In Chapter 9, we'll implement a Web Forms UI based on the same set of business objects. Although there are obvious differences between the Windows Forms and Web Forms environments, we'll achieve total reuse of our business logic and data- access code as we move from one UI type to the next .