Layers and Components

In my previous post, I summarized layers and tiers. In this post, I'll walk through the key components of the layers. This exercise is part of our patterns & practices App Arch Guide 2.0 project.

Layers and Components
Here's a visual of a layered architecture and relevant components:

Note that this is just an example of common components and layers. Your scenarios may vary.

Presentation Layer Components
Here's typical presentation layer components:

User interface (UI) components. Your user interface components (controls) provide a way for users to interact with your application. They render and format data for users and acquire and validate data coming in from them.
User process components. Your user process components help synchronize and orchestrate user interactions. This way the process flow and state management logic is not hard-coded in the user interface elements themselves, and the same basic user interaction patterns can be reused by multiple user interfaces.

Business Layer Components
Here's typical business layer components:

Application Facade. (Optional). Your application facade maps your business logic to your application. It's optional and it depends on how reusable and generic your business logic is. If your business logic was written specifically for your application, then you probably don't need an application facade.
Business components. Your business components implement business rules and perform business tasks.
Business workflows. Your business workflows define and coordinate long-running, multi-step business processes. They can be implemented using business process management tools.
Business entity components. Your business entity components represent actual business entities (for example products or orders.) You use them to pass data between components. They're usually data structures (such as DataSets, DataReaders, or XML streams), but they can also be implemented using custom object-oriented classes.

Data Layer Components
Here's typical data layer components:

Data access logic components. Data access components abstract the logic necessary to access. Doing so centralizes data access functionality and makes it easier to configure and maintain.
Data Helpers / Utilities.
Service agents. Your service agents help you call external services. They do so by mapping the format of the data exposed by the service to the format your application uses, as well as help manage the semantics of calling the services.

Cross-Cutting

Cross-cutting components. This includes components components to perform exception management, to authorize users to perform certain tasks, and to communicate with other services and applications.

Feedback
Does this match what you see in practice?

Additional Resources
Here's some relevant links:

My Related Posts

Comments

Anonymous
September 06, 2008
The comment has been removed
Anonymous
September 07, 2008
As part of our patterns & practices App Arch Guide 2.0 Project , I'm scanning Microsoft for helpful
Anonymous
September 09, 2008
As part of our patterns & practices App Arch Guide 2.0 project , we're consolidating our information
Anonymous
September 11, 2008
One of my colleagues on the patterns & practices team, David Hill , collected and distilled feedback
Anonymous
September 17, 2008
As part of our patterns & practices App Arch Guide 2.0 project , we've created a set of application
Anonymous
September 24, 2008
As part of our patterns & practices App Arch Guide 2.0 project , we've put together an arch frame. 
Anonymous
September 26, 2008
I added a brief over deck of our patterns & practices App Arch Guide 2.0 project to codeplex: App
Anonymous
October 06, 2008
Hi, I am preparing a course where I will be guiding the students through a project in dot net 3.5 - using the layered architecture. Do you happen to have some basic code for a sample application where I could start from? Or do you have any idea how I could find something like that? Thanks adinamilston@gmail.com
Anonymous
October 07, 2008
@Adina There's two examples you can use to get started: