• Choose a category
• All
• Classic-Fiction

By Root 5614 0

you also see different blocks referring to services. The service layer is made of a collection of methods with a coarse-grained interface that I refer to in the figure as macro services. These services implement use-cases and do not contain any domain logic. Micro services, conversely, are domain-logic services you control or just autonomous services that your BLL needs to consume.

Exposing Entities to the Presentation Layer

In a service layer, you should have only methods with a direct match to actions in a use-case. For example, you should have a FindAllOrders method only if you have a use-case that requires you to display all orders through the user interface. However, you should not have such a method if the use-case requires the user to click a button to escalate all unprocessed orders to another department. In this case, there’s no need to display to the user interface (and subsequently to roundtrip from the service layer) the entire list of orders. Here’s a sample class in a service layer:

public interface IOrderService

{

void Create(Order o);

IList FindAll();

Order FindByID(Int32 orderID);

}

public class OrderService : IOrderService

{

...

}

A fundamental point in a service layer is the types used in the signatures. What about the Order type in the previous code snippet? Is it the same Order entity you might have in the domain model? Is it something else?

In general, if you can afford to expose domain model objects in the service contract, by all means do that. Your design is probably not as pure as it should be, but you save yourself a lot of time and effort. You must be aware that by using the same entity types in the presentation layer and BLL, you get additional coupling between the presentation and business layers. This is more than acceptable if the presentation and business layers are within the same layer. Otherwise, sharing the domain model forces you to have the same (or compatible) runtime platform on both sides of the network.

Data Transfer Objects

If you’re looking for the greatest flexibility and loose coupling, you should consider using ad hoc data transfer objects (DTO). A data transfer object is a plain container shaped by the needs of the view. A data transfer object contains just data and no behavior.

When you use data transfer objects, you likely need an extra layer of adapters. An adapter is a class that builds a data transfer object from a graph of domain entities. An adapter is bidirectional in the sense that it also needs a method to take a data transfer object coming from the presentation and break up its content into pieces to be mapped on entities.

The additional workload required by using data transfer objects is significant in moderately complex projects also. In fact, you need two adapters (or translators) for each data transfer object and likely two data transfer objects for each service layer method (one for input and one for output.)

It’s not a matter of being lazy developers; it’s just that a full data transfer object implementation requires a lot of work.

Note

Effective tools are a great way to make a full DTO implementation affordable and, to some extent, sustainable. A common tool that really saves you a ton of work is AutoMapper. (See http://automapper.codeplex.com.) AutoMapper is an object-to-object mapper that employs a convention-based algorithm. All it does is copy values from one object (for example, a domain entity) to another (for example, a DTO) using a configurable algorithm to resolve mapping between members. At this point, AutoMapper can be easily considered a best practice in modern development.

The Data Access Layer

No matter how many abstraction layers you build in your system, at some point you need to open a connection to some database. That’s where and when the data access layer (DAL) fits in. The DAL is a library of code that provides access to data stored in a persistent container, such as a database. In a layered system, you delegate this layer any task that relates to reading from, and writing to, the persistent