My company decided to break its monolithic build and make our life easier. The main idea was to move from Jini services to Protocol-Buffers over RESTful API.
The main reasons were to introduce loose coupling between our services, adopt open standards, and become cool ;-).
I will probably discuss all this in a later post. The reason I am mentioning all this is that it raised the issue of transforming value objects back and forth. We are all faced with this issue when developing enterprise software. For example, you create objects in your DAO layer. These are passed to domain objects that massage them a little. Later these objects are passed to your service layer, controller, and presentation layer.
Some of you are probably saying right now, “Are you really coupling all these layers”? Well, no… Most of us will go and transform the Value Objects (VOs, or DTOs) to another form when passed between the layers. All this copying and transforming is extremely repetitive and time consuming.
When we started working with protobuf, I quickly noticed that transforming protobuf messages into our domain model is going to be an issue. To avoid decoupling between services, each service has to write its own transformation code. This requirement poses a high risk of code duplication (I know some will argue you can’t really call it duplication). My idea was to introduce XML object to object mapping rules.
In comes Dozer. Dozer is a Java Bean to Java Bean mapper that recursively copies data from one object to another. It has many cool features, but lacks the ability to transform your objects into immutable objects – Dozer has no support for constructor arguments. Making your VO classes immutable is desired when you are not administrating them, and when these objects are going to be placed in caches.
Unfortunately, I don’t have a solution to the immutability issue (but more will come - I promise). I have started a private project that will either extend Dozer to support constructor args (hard…), or utilize for its features while extending its abilities to do so (somewhat easier).
I just wonder how many of you stumbled into this…
The main reasons were to introduce loose coupling between our services, adopt open standards, and become cool ;-).
I will probably discuss all this in a later post. The reason I am mentioning all this is that it raised the issue of transforming value objects back and forth. We are all faced with this issue when developing enterprise software. For example, you create objects in your DAO layer. These are passed to domain objects that massage them a little. Later these objects are passed to your service layer, controller, and presentation layer.
Some of you are probably saying right now, “Are you really coupling all these layers”? Well, no… Most of us will go and transform the Value Objects (VOs, or DTOs) to another form when passed between the layers. All this copying and transforming is extremely repetitive and time consuming.
When we started working with protobuf, I quickly noticed that transforming protobuf messages into our domain model is going to be an issue. To avoid decoupling between services, each service has to write its own transformation code. This requirement poses a high risk of code duplication (I know some will argue you can’t really call it duplication). My idea was to introduce XML object to object mapping rules.
In comes Dozer. Dozer is a Java Bean to Java Bean mapper that recursively copies data from one object to another. It has many cool features, but lacks the ability to transform your objects into immutable objects – Dozer has no support for constructor arguments. Making your VO classes immutable is desired when you are not administrating them, and when these objects are going to be placed in caches.
Unfortunately, I don’t have a solution to the immutability issue (but more will come - I promise). I have started a private project that will either extend Dozer to support constructor args (hard…), or utilize for its features while extending its abilities to do so (somewhat easier).
I just wonder how many of you stumbled into this…
No comments:
Post a Comment