Transaction Script, Doam, Model, Logic SQL
Tomhornson # (at) # Hotmail.com
12/6/2004 in Lushan
First, the beginning of the story
I didn't pay attention to Domain Model, and I don't know what is transaction script and it and Domain Model are non-non-not. For me, everything is from an article in Martin Fowler.
In November 2003, Martin Fowler dragged Eric EvansV (Domain-Driven Design, "Domain-Driven Design: Tackling Complexity In The Heart of Software" Author) published a battle entitled "AnemicDomainmodel" . This stone is really unsaled, and many people have begun to pay attention to the issue of Transaction Script, Domain Model. In fact, before this, Martin wrote a "Domain Logic and SQL" says the inferior part of Transaction Script.
Before you continue to read this article, it is recommended that you first pass the above related links to understand the beginning of the matter.
Second, what is Transaction Script, what is Domain Model?
In fact, Martin's "Domain Logic and SQL" is a very detailed comparison of Transaction Script, Domain Model, Logic SQL, the complexity, performance, scalability, portability, testability, etc. from the program.
Third, my analysis and conclusion
I personally disagreed with the RichdomaInmodel of Martin. Because, I feel that Richdomainmodel often, especially in the data application system, there is no situation in the real world. It is not said that the object needs to contain data and action. For example, a bank Account transfer, press Martin's ideas, moderately add member functions such as a WITHDRAW (Long Mount), but it is clear that bank account is reflected in the real world and should be a bank account. A record that is just an information carrier, no self-motivation, Withdraw should be modeled into a class such as AccountManger. Abstraction like Account and Person, Person in real life, this is originally self-motivated, such as Say (String Words).
Of course, it is undeniable that you can see from Martin's "Domain Logic and SQL", you can see that RichDomainModel is indeed a lot. However, it does not mean those benefits brought by richdomainmodel, say it is the right idea.
My personal opinion: Martin does not have the so-called Transactionscript method to truly reflect reality and is the result of natural OO modeling. Although RichDomainmodel brings some programming, the benefits of architecture, but it is deformed.
Here, I still want to emphasize that the advantages of using RichDomainmodel are different from the advantages of using different technologies. For example, you use Hibernate persistence, then its advantages are almost gone.
IV. Currently, I am more common technology and architecture in actual development (for small and medium-sized data applications) | ---> Transaction / not transaction "Presentation ----> façade - | ---> DataServices ------> Hibernate -------> DB | ----> And so ON Description:
1, DataServices, services across DataServices, their specific implementations are determined in the same transaction based on whether the latter requires the called DataServices being called. If, the latter does have this requirement, using localthread to solve it.
2. Whether INJECT DataServices in Facade is in your needs, but if you use Spring to INJECT, the DataServices calling across DataServices services will not be possible. (At least, I didn't think of the way.)
Revision: First: 12/6/2004
