General Design Recommendations for Applications and Services

When designing an application or service, you should consider the following
recommendations:

- Identify the kinds of components you will need in your application. Some
applications do not require certain components. For example, smaller applications
that don’t need to integrate with other services may not need business
workflows or service agents. Similarly, applications that have only one user
interface with a small number of elements may not require user process
components.

-  Design all components of a particular type to be as consistent as possible, using
one design model or a small set of design models. This helps to preserve the
predictability and maintainability of the design and implementation for all
teams. In some cases, it may be hard to maintain a logical design due to technical
environments (for example, if you are developing both ASP.NET- and Windowsbased
user interfaces); however, you should strive for consistency within each
environment. In some cases, you can use a base class for all components that
follow a similar pattern, such as data access logic components.

- Understand how components communicate with each other before choosing
physical distribution boundaries. Keep coupling low and cohesion high by
choosing coarse-grained, rather than chatty, interfaces for remote communication.


- Keep the format used for data exchange consistent within the application or
service. If you must mix data representation formats, keep the number of formats
low. For example, you may return data in a DataReader from data access logic
components to do fast rendering of data in Microsoft ASP.NET, but use DataSets
for consumption in business processes. However, be aware that mixing XML
strings, DataSets, serialized objects, DataReaders, and other formats in the same
application will make the application more difficult to develop, extend, and
maintain.

- Keep code that enforces policies (such as security, operational management, and
communication restrictions) abstracted as much as possible from the application
business logic. Try to rely on attributes, platform application programming
interfaces (APIs), or utility components that provide “single line of code” access
to functionality related to the policies, such as publishing exceptions, authorizing
users, and so on.


- Determine at the outset what kind of layering you want to enforce. In a strict
layering system, components in layer A cannot call components in layer C; they
always call components in layer B. In a more relaxed layering system, components
in a layer can call components in other layers that are not immediately
below it. In all cases, try to avoid upstream calls and dependencies, in which
layer C invokes layer B. You may choose to implement a relaxed layering to
16 Application Architecture for .NET: Designing Applications and Services
prevent cascading effects throughout all layers whenever a layer close to the
bottom changes, or to prevent having components that do nothing but forward
calls to layers underneath.