2

When designing a service layer, should I use my domain objects in the interface contract? For example:

public void registerUser(String username, String realName)

VS

public void registerUser(User user)

Should the domain objects be constructed in the client code or behind the service facade?

I'm using EJB and my clients would be a locally deployed web application, RMI client and maybe a web service client.

Nefron
  • 689
  • 6
  • 10

6 Answers6

5

Technically, there's no problem in using one or another: Web Service through XSD is capable of supporting primitive types like Strings and complex objects like your User class.

Now, what if your User class has 20 attributes and you only need username and realName to register a user? In that special case it would be better to use your first approach because less bandwidth is needed are your not forcing your client that construction of a big XML document that's not needed.

Other scenario is that your User class produce a complex and highly-nested XML document according to JAXB rules. That can produce complex messages for your client and also complex client-implementations. If that's the case, you could use a simpler version of your Domain Class -maybe with one or two nesting levels- as a DTO to simplify message interchange.

Carlos Gavidia-Calderon
  • 6,905
  • 8
  • 30
  • 58
1

In my opinion, Service layer in general shouldn't use domain objects. Domain is something that handles business logic, rules and workflow, while service provides an interface to it.

The simplest principle when designing service layer is "service method realized a single use case". (Use case is a scenario with both inputs and outputs defined pretty well).

In your sample - registerUser(String username, String realName) - looks completely fine. Service would instantiate all required domain objects and initiate business operation - in the same time, service clients are unaware of business logic internals (for example, there could be some specific in User object construction, etc.)

mikalai
  • 1,716
  • 13
  • 23
0

There seems to be no harm in passing the User object through-out all your services. According to DDD (Domain Driven Design http://en.wikipedia.org/wiki/Domain-driven_design ) this is a very good practice and all your domain object should available across all the layers in your project. In the long run it will make you code more object oriented which is usually seen lacking in a typical Java EE project (aka anemic domain model) but the only additional recommendation is you try to keep business logic within the User class and not in your service.

Arjan Tijms
  • 36,666
  • 12
  • 105
  • 134
Sameer Patil
  • 516
  • 4
  • 13
0

Passing Domain objects as part of the Service layer is a way much simpler and more object oriented. Working with the user input values and constructing relevant Domain objects - is the responsibility of the Controller layer

Moreover Service layer describes the API to be used by end Clients. If the Service layer starts exposing API with generic types (like String, Maps etc) then trouble starts.

Instead of DTOs which is an anti-pattern Domain objects are better equipped to be passed from Controller layer to Service Layer.

Community
  • 1
  • 1
basav
  • 1,433
  • 10
  • 18
0

In my opinion, it is not suitable to expose domain object from facade layer. Clients that are using the service should not be depended to domain objects. It is better to designing a data contract and expose them from facade layer. They will be used just for transferring data, and that is DTOs. Consider that domain objects are not just DTOs and they can provide some functionless. Also a service in facade layer expose a usage of system and it may includes the collaboration of some parts of multiple domain objects and sometimes there may be not a suitable mapping between the requirements of the method in facade layer and available domain objects. Also DTOs and their structure may require some considerations for network performance reasons. And these considerations usually are not meaningful in designing domain objects.

Farshid Saberi
  • 837
  • 12
  • 15
0

Should the domain objects be constructed in the client code or behind the service facade?

Domain objects should be created on service side. Client merely passes all parameters required to create an object.

A general algorithm of object construction is:

  1. Get parameters
  2. Validate parameters
  3. Pass valid parameters into object constructor to get a valid object
  4. Register a valid constructed object in repository for persistence (if necessary)

If an object is created on client side and passed to service, then several problems rise:

  1. The object from client side may be in the incorrect state (client data can not be trusted)
  2. Object state has to be validated
  3. Validation of an existing object means possible duplication of validation logic, possible loss of encapsulation when private field values are validated or sometimes single responsibility principle violation
  4. Sometimes service has to reconstruct the object using passed object property values as parameters
Lightman
  • 892
  • 10
  • 20