8

Martin Fowler suggests using a service layer as a boundary between the domain model and and "Data Loaders". However, Rockford Lhotka suggests building validation into the business object itself and this is exactly what CSLA.NET does.

The benefits of abstracting this into a service layer is obviously that your service layer can coordinate the activity/operation across multiple business objects. But what are the other advantages and disadvantages of using a service layer over directly using business objects for business logic and validation?

3 Answers3

4

I'm not sure if you have figured this out.

Martin Fowler suggestion in the PEAA is the Service layer an API between the UI (or clients) and the Domain/Data layers. it will expose any functionality that can be consumed by a client.

If you look at the Domain Model (Here)

An object model of the domain that incorporates both behavior and data.

The Domain tier will contain these objects, which will have actions/validation (Behaviour) and state (Data)

These objects can be reused in other applications, this will also depend upon your design. the domain layer should not be dependent on the service layer

So considering that Domain objects have behaviour (this includes validation) and data. the Service layer is what you want your application to expose (to functionaly do). IE add a customer, or account, calcualte the Bills for the end of month.

Have a look at sharp architure's layout (http://www.sharparchitecture.net/)

This is my understanding of this meterial.

HTH

bones

mattruma
  • 16,084
  • 31
  • 98
  • 163
dbones
  • 4,126
  • 2
  • 33
  • 48
3

I am definately in the camp of Rocky Lhotka. I believe that your business objects should be very easy to "port" between applications and UI layers. Adding an additional "service layer" will most likely add a dependency with your objects and therefore make them less "portable".

If you write your business object framework correctly, your business objects should be able to handle the validation correctly between various business objects. CSLA.NET does this correctly by having parent/child relationships as well as the concept of dependent property validtion.

Jamie Wright
  • 1,152
  • 10
  • 22
  • I'd also add that some business objects may exist to do coordination as well. For example, you wouldn't write the behaviors needed to convert an order to an invoice, you'd have an OrderConverter that will check an order and if valide convert it. What I typically see as "service" objects are basically a dumping ground of barely related methods. They all do something to a store, but other than that are not related. In Csla these methods would typically be encapsulated into separate classes which has full knowledge of the use caselthat is, it knows everything about how to make an order an invoice – Andy Mar 29 '11 at 12:56
0

I'm looking for a more flexible Domain Model where there is a separation of Data and Behavior, but I don't believe the Service Layer is the appropriate layer for the behavior. Instead, perhaps, one could take a simple Business Logic Layer approach where Business Entity objects only expose data and Business Process objects only expose behavior, and among those behaviors are validation methods.

One benefit, depending on how loose business process coupling is, you could apply validation to a wider range of covariants and possibly even invariant types. Consider for a moment validating "FirstName" and "LastName" fields, and further consider that these fields may, in any large system, exist on a half dozen or more different entities. Separating process from data would ensure you could implement your validation processes once and apply them over many objects which provide the same data.

I've noticed that the ideal that the Domain Model 'should be' comprised of Domain Objects which are a fusion of both Data and Behavior is a concept of Fowler/Evans, circa 2000-2002 (shortly following a rapid migration toward distributed information systems instead of 2-tier applications.)

Thoughts?

Shaun Wilson
  • 8,320
  • 3
  • 46
  • 46