Good article talking about serive layer
骇人听闻的装修工程
2009/04/13 09:51 | by
One day, some friend ask me, why grails so looks like the rails, but there's a service layer in this framework.
It's a common question asked by buddy from rails framework.
I'm confused also when just got stating in grails.
I decide to talk about this topic in article, I think most of the idea is just came from myself, may be it's not alright, I just hope it can resolve some confuse and question from newer.
The most different between grails and rails, I think it's focus on grails is domain-Driven, this is came from some special area such as UML and BA. Programmers always not care about the UML and BA in most project. but they are always received some information about domain, entity, model, role, behavior, wow, it's so much nouns, hard to understand, no problem. I talk about them just since they are relative with the DDD.
Some buddies from rails framework is familiar with rich model object, right? That's important concept in rails model layer, we are always like witting model-related logic in model, it's different from java or ejb, an anemia model object language, But are you confused when you see thousands lines of code in the models? Are you feeling why it so far to get ending of the code when you have read the model's code for 1 hour?
Grails choose an standpoint between grails and ejb model, they choose DDD.
It's so familiar with the rails framework when you just get starting with grails, model properties, model constraints and model mapping such as belongsTo and hasMany.
But when you want to add some business logic, problem came out.
Where to add logic? In rails user opinion, coding in domain model is conversion, but why there's a service layer in grails, if we write logic into service layer, how to explain the constraints and validation in domain objects?
It looks like some important concept in UML, domain-entity-role-behavior.
Example: in a pet store. We have three domain, store, pets, customers.
store has-may pets, customer can buy pets and also has-many pets.
the constraints is pets can not have no store but can null in owner(Customer) object.
the pets' price can not little than zero.
The customer must have non-null name and they must have enough money to buy pets.
the constraints is the meta information of domain, so this logic add to domain class.
when this domain get a instance in back-end, we can call them entity. entity can be described with the relation between each others, and entity has validation them self.
exclude entity concept, the customer, pets and store are also roles, why?
They have behavior, customer have behavior to buy, to pay and to complain.
The pets can shout, and the store can publish pet information.
Ok, where to put behavior code? Not controller layer, not domain layer or not script SRC in grails also. just in the service layer.
More advantage? Yes, service layer can inject into everywhere in the grails framework, so ,if someone want to reuse logic in other place, go ahead.
Service layer can be as an open service API, in web service.
Example, store and customer must login when store want to publish information and customer want buy pet, It's the same logic when auth them, username + password [+ verification code].
You can just write a LoginService in application and inject into store and customer domain(controller) to use.
And when you just want to open a auth API for user from another system, you can use this service as an open API(webservice).
After all, we have some idea when we choosing where to put the different logic, right?
After all, believe and trust DRY concept when you use this Agile Web Framework, that's the most important you must to remember!
It's a common question asked by buddy from rails framework.
I'm confused also when just got stating in grails.
I decide to talk about this topic in article, I think most of the idea is just came from myself, may be it's not alright, I just hope it can resolve some confuse and question from newer.
The most different between grails and rails, I think it's focus on grails is domain-Driven, this is came from some special area such as UML and BA. Programmers always not care about the UML and BA in most project. but they are always received some information about domain, entity, model, role, behavior, wow, it's so much nouns, hard to understand, no problem. I talk about them just since they are relative with the DDD.
Some buddies from rails framework is familiar with rich model object, right? That's important concept in rails model layer, we are always like witting model-related logic in model, it's different from java or ejb, an anemia model object language, But are you confused when you see thousands lines of code in the models? Are you feeling why it so far to get ending of the code when you have read the model's code for 1 hour?
Grails choose an standpoint between grails and ejb model, they choose DDD.
It's so familiar with the rails framework when you just get starting with grails, model properties, model constraints and model mapping such as belongsTo and hasMany.
But when you want to add some business logic, problem came out.
Where to add logic? In rails user opinion, coding in domain model is conversion, but why there's a service layer in grails, if we write logic into service layer, how to explain the constraints and validation in domain objects?
It looks like some important concept in UML, domain-entity-role-behavior.
Example: in a pet store. We have three domain, store, pets, customers.
store has-may pets, customer can buy pets and also has-many pets.
the constraints is pets can not have no store but can null in owner(Customer) object.
the pets' price can not little than zero.
The customer must have non-null name and they must have enough money to buy pets.
the constraints is the meta information of domain, so this logic add to domain class.
when this domain get a instance in back-end, we can call them entity. entity can be described with the relation between each others, and entity has validation them self.
exclude entity concept, the customer, pets and store are also roles, why?
They have behavior, customer have behavior to buy, to pay and to complain.
The pets can shout, and the store can publish pet information.
Ok, where to put behavior code? Not controller layer, not domain layer or not script SRC in grails also. just in the service layer.
More advantage? Yes, service layer can inject into everywhere in the grails framework, so ,if someone want to reuse logic in other place, go ahead.
Service layer can be as an open service API, in web service.
Example, store and customer must login when store want to publish information and customer want buy pet, It's the same logic when auth them, username + password [+ verification code].
You can just write a LoginService in application and inject into store and customer domain(controller) to use.
And when you just want to open a auth API for user from another system, you can use this service as an open API(webservice).
After all, we have some idea when we choosing where to put the different logic, right?
After all, believe and trust DRY concept when you use this Agile Web Framework, that's the most important you must to remember!
