The Service Layer

• The service layer contains operations that script the domain model and invoke application services in a sequence that is mostly determined by use cases. The service layer responds to input coming from the presentation layer.
• If a use case changes, the service layer may change but the business logic stay intact.
• Should avoid having methods with a finer granularity than the business event (use case) that triggers them (i.e prefer chunky interfaces over chatty interfaces)
• Neither the presentation layer nor the service layer contains (or should contain) business logic. The presentation layer knows only about the coarse-grained interface of the service layer; the service layer knows only about a contracted set of feasible interactions and takes care of the nitty-gritty details: transactions, resource management, coordination , data massaging, role management, data validation, notification and adaptation of the data to the user interface or to the format that integrated systems might require.
• Can be separated across physical boundaries if there is a benefit in doing so, otherwise keep the layer but keep it local (this can be swapped out across physical boundaries later).
• The service layer interface will probably use data transfer objects to accept and return data, and it will prefer chunky methods over chatty methods so that it can minimize roundtrips and maximize throughput.
• Service classes created much like the Transaction Script method, split up as appropriate, such as CustomerSerivce, OrderService etc.
• WCF RIA Services Use with Silverlight/WPF solutions that need to communicate back to the server. The RIA Services Essentials project contains sample applications and here is a demonstration.

Thoughts on Application Logic vs Domain Logic

• Application logic has clear dependencies on application use cases and the user interface. Incorporating this logic in the domain model would make the classes in the domain inherently less reusable.
• Entities in the domain logic are mostly standalone objects and have limited knowledge of other entities. Any interaction between entities (such as creating, deleting, or commanding entities to do something) is orchestrated by the service layer but is managed by domain logic. The only interaction between entities that is acceptable in the domain logic relates to logical dependencies between entities, such as Orders and Order Details.

Data Transfer Object (DTO) Considerations

• Customised flat objects serialized to and from the service layer to the presentation layer.
• DTO Adapter classes used to convert between domain objects and DTO objects.
• Benefits:
  • Provides abstraction from the Domain Model (can change independently without breaking clients).
  • Can increase performance by serializing and returning only the data required in the presentation (not a bloated Domain Model object with all refereced objects in the graph)
  • Avoids problems with not being able to serialize and return domain model objects that have circular references (i.e can't return Customer -> Order where Order also has reference to Customer).
• Negatives
  • Can be unwieldy to manage multiple DTO's for every domain object and the translations between each.
• One approach is to use domain objects where possible and DTO's where necessary, although doesn't follow strict Service Oriented Architecture.
• Can avoid them altogether if the presentation and service layer are within the same physical boundary, and the domain model assembly can be shared in this case (no issues with serialization of circular references).
• A good commentary about the pros and cons of using DTO's.

Service Oriented Architecture

• Pushes loosely coupled, service-based architecture to model business processes.
• Versioned.
• More of a philosophy than anything physical. Not necessarily a web service but a web service may come as a result of applying SOA.
• Ideal for when the organisation that creates the service is not the same as the organisations that create the clients that consume the service.

AJAX Service Layer

An AJAX Service Layer is an additional wrapping over the service layer. Request / Response should use JSON, which is a format that can be loaded directly into the javascript eval function. All requests to the AJAX Service Layer needs to ensure clients are properly authenticated as necessary. Best way to do this is to use:

• ASP.NET Forms Authentication
• WCF with aspNetCompatibilityEnabled
• Check HttpContext.Current.User (populated by the ASP.NET authentication cookie).