Deborah's Developer MindScape






         Tips and Techniques for Web and .NET developers.

January 21, 2016

Dividing a C# Application into Components

Filed under: C# @ 2:52 pm
Tags: , ,

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.

image

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.

image

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!

4 Comments

  1.   AliBayat — January 23, 2016 @ 11:36 am    Reply

    Thanks for you great post

  2.   Ali Bayat — March 23, 2016 @ 9:34 am    Reply

    Great post. I follow the same principles you do here.

  3.   James — February 26, 2017 @ 6:42 am    Reply

    1) If Entity Framework is not used, then would the direct database access code go in the Repository Classes? Would that mean that there is no separate data access layer? That would be fine in that case to not have a separate data access layer?

    2) Is there any recommended business layer folder naming structure for larger projects? I think in the of your PluralSight videos it mentioned using “UM” for User Management and PM for Product Management as an example. Is that the approach you use?

    •   deborahk — March 27, 2017 @ 1:55 pm    Reply

      #1 – I don’t use EF and build my own Data Access Layer component using ADO.NET.

      #2 – Yes. I try to keep the folder names short but clear on what they are.

      Hope this helps!

Trackbacks/Pingbacks

  1. Dew Drop – January 25, 2016 (#2173) | Morning Dew

RSS feed for comments on this post. TrackBack URI

Leave a comment

© 2018 Deborah's Developer MindScape   Provided by WPMU DEV -The WordPress Experts   Hosted by Microsoft MVPs