Layered Architecture & Separation of Concerns

Now that I have dealt with my philosophical and project management issues, we can get back to improving the design of the World of Art web app. If you recall my previous post on Improving the Design, I identified several objectives for improving the application design;

  • Eliminate the tight coupling of the user interface and data access, by extracting database connectivity and data access, into a separate architectural layer of the application.
  • Design and build an abstracted view of the data access domain.
  • Develop an interface to the data access domain.

A tremendous amount of progress towards meeting these objectives, can be gained by implementing the Microsoft ADO.NET Entity Framework. The Entity Framework provides a means for achieving our design objects. However, the Entity Framework provides even greater benefits;

  • Enables me to program against a conceptual application model instead of programming directly against a relational database schema.
  • Decreases the amount of code and maintenance required for data-oriented applications.
  • Provides freedom to focus more on the problem/business domain issues, and much less on database access and query issues.

Now with all that said, the ADO.NET Entity Framework is no the complete solution for improving the design of our application. The core purpose of our design objectives is to establish a separation of concerns, by creating distance between dissimilar aspects of our code.

Separation of Concerns

Kyle Baley, Donald Belcham and James Kovacs, wrote an excellent series in MSDN Magazine called Extreme ASP.NET Makeover. Part six of this series deals with the subject of separation of concerns.

Another design improvement objective, is to introduce a layered architecture to our design. The traditional layered architecture of a software application, utilizes three basic layers for separating coding concerns;

  • User Interface
  • Business Logic
  • Data Access

Layered Architecture

Applying a layered architectural design to an app is always good practice, because it simplifies each component of the app, and improves maintainability in a way that lends itself very nicely to evolutionary improvements, as opposed to total re-writes. However, applying a layered design to large, complex, enterprise level applications, can introduce other levels of tight coupling which should be avoided.

Hendry Luk wrote a very good piece on this subject. See Software Development Fundamentals, Part 2: Layered Architecture

Jeffrey Palermo also tackles this issue in his series on The Onion Architecture.

Please keep in mind, the concepts covered by Hendry Luk and Jeffrey Palermo, are intended for large enterprise level apps, with complex behaviors and long running life cycles. However, it is good to study and understand these concepts. As developers, it is our responsibility to determine the best practical application of these concepts, based on a desire to satisfy our customer’s needs and our project requirements.

In my next post, we will introduce a Data Model Layer to our application. In this layer, we will utilize the ADO.NET Entity Framework, to create an object model over the World of Art Relation Database.

2 thoughts on “Layered Architecture & Separation of Concerns

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">