Spring Entity to use Service, possible design flaw, but still....

Question

Hi guys,

The legacy database I'm "springwrapping" has Id's that are Strings and that give away some information. For instance, a UserId looks like "DK-6715-00001", meaning a user in Denmark, postal code 6715. This is so wrapped into the enterprise applications that it needs to be kept and my entities verify this in their setter methods.

But, User also has the fields country and postal code, so when an Id for the bean is set, it might as well also set country and postal code. For this, it needs the CountryService to look up that Dk is the Denmark Country object, and look up 6715 with the newly found Country object in PostalService.

First of all, can I wire this up so that I can access CountryService and PostalService from my Entity object? (Entities are defined long before the service objects in my bean definition) Second of all, this should violate any nice design principles. Is there a better design I could do then to let my entities carry references to service beans?

Cheers

Nik

Answer 1

If you're looking for design advice, here's my $0.02: Entities should not have references to service beans. Services should operate on entities, not the other way around. So if you find that you need a reference to a service in one of your entity classes, it's probably an indicator that there is too much business logic inside the entity class. As a rule of thumb, business logic is OK inside an entity class as long as the logic only deals with that single object or is quite simple (e.g. an equals method). But if business logic is "cross-entity" (involving more than one entity object), it should be implemented in a service bean.

If you don't care what I think and you just want to make your design work: You can inject Spring bean references inside entities using AspectJ. I believe it requires an extra compile step and/or runtime support from AsjectJ. There is no way to do it with Spring proper because the service objects would need to be injected at the time the entity object is created with the new keyword, which Spring doesn't support.

Answer 2

It sounds like this is logic that should be placed in a Controller.

That UserCreationController (with the possible addition of a UserService) should have references to those CountryService or PostalService, and (maybe) JdbcService or HibernateService depending on your app.

Entity classes (or POJOs) should err on the side of simplicity.

Edit: It's the business logic that separates the two. The controller receives the form data, maps that to your domain entity, calls your business logic (service/s) and based on the result, decides where the user shall go.

Answer 3

Hi guys, thanks for your input. I've decided that it is indeed a design flaw, and that I was thinking the wrong way about it. I should totally remove the setter-method for the Id property, and just have a getter for it, and then have setters and getters for the other properties that make up the Id. This way, I don't have to work hard to ensure that the Id formatting becomes correct, and I don't have to access any services.

Cheers

Nik