Deborah's Developer MindScape

A good architecture divides an application into components:

• We build UI classes in the UI layer
• Domain entity classes in the business logic layer
• Data access classes in the data access layer.
• And library classes in the common library component.

The content for this blog post was taken from the Pluralsight course entitled “C# Best Practices: Improving on the Basics“. Check out this course for more information.

UI Layer

When we add a form to a UI component, such as a Windows Forms, WPF, or a Web Forms project, Visual Studio automatically creates a form class for us. So our application will have one class for each form. The form class should contain code that:

• Responds to form events by calling the business logic layer to perform needed processing.
• Includes error handling for any errors that occur.

There is another type of class that you may find in the UI layer, and that is a V/M or View/Model class. A View/Model manages the data and interaction for a single form or view. A View/Model class is often used in cases where the user interface can bind directly to data defined in the View/Model class, such as with WPF.

Business Logic Layer

When defining classes for the business logic of an application we can start by defining a domain model. A domain model identifies the basic business entities to be managed by the application and how they are related.

For example, if Acme Inc needs a feature to order more product inventory from a vendor, we can define a domain model that includes

• An order.
• The product to order. So the order “has a” product.
• And the vendor from whom the company buys that product. So the product “has a” vendor.

We can use the domain model as a starting point for defining the classes in the business logic component. We’ll need a class to manage each order, a class to manage product information, and a class that manages each approved vendor.

Defining the domain model helps us to consider all of the different bits of logic that the application will require and organize that logic into appropriate classes.

Also in the business logic layer we may want Repository classes. Repository classes are responsible for managing the in memory repository of data for the application. For example, when the user requests display of a specific vendor and the products purchased from that vendor, the Repository classes are responsible for getting that data, tracking the state of that data (for example, whether it has been changed) and saving that data using the data access layer.

Data Access Layer

The classes in the data access layer depend on the data access strategy you are using. If you are using Entity Framework, you may not need any classes in this layer because Entity Framework defines them for you.

Common Library Component

We can determine whether specific functionality goes into a library component by looking at the other components. If the functionality is common across layers (or across applications), then it may be better in a library component. For example, code that provides logging, or sends out email.

Conclusion

When is it appropriate to divide an application into components and define classes such as these? Maybe always? Even if we are developing a prototype, way too often that prototype becomes the basis of our real application.

By breaking the application into a set of components early on in the development cycle we start with a strong foundation that can support the application as it grows and changes over time.

Enjoy!