[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
Kengkaj Sathianpantarit wrote:
DTO has nothing to do with any business rule, its main purpose is to reduce number of remote calls.
I mean they are not supposed to minimize impacts when business rules have changed, that is just not the purpose of this pattern.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
manish ahuja wrote:
option2) expose the domain object to the client apps. Now this domain object actually comprises the business logic too.
SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
Kengkaj Sathianpantarit wrote:
manish ahuja wrote:
option2) expose the domain object to the client apps. Now this domain object actually comprises the business logic too.
If you mean remote interface and you want to reduce remote calls, using DTO is a good option.
If the client apps invoke a method on the domain object, it will call remote method on the server, because processing must happen on the server-side. You understand this right?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Ilja Preuss wrote:
Kengkaj Sathianpantarit wrote:
manish ahuja wrote:
option2) expose the domain object to the client apps. Now this domain object actually comprises the business logic too.
If you mean remote interface and you want to reduce remote calls, using DTO is a good option.
If the client apps invoke a method on the domain object, it will call remote method on the server, because processing must happen on the server-side. You understand this right?
That's not necessarily true. If the functionality in the domain object is self-contained (that is, it doesn't need other server functionality), the DO could just be serializable and the business logic executed on client side.
SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
Ilja Preuss wrote:There is possibly a third option, as I tried to say above: only expose interfaces to the client. That's especially simple if the client is actually running in the same JVM.
SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
Kengkaj Sathianpantarit wrote:
In sever-client applications, it's very rare for the client to be able to execute business logic on its own.
Even in that case it is strange that why the server needs to send a domain object to the client, the server can send just a command String (or any kind of data the client can parse), and the client can create domain object and execute a method on its side. So no need to send an object.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Ilja Preuss wrote:
Kengkaj Sathianpantarit wrote:Even in that case it is strange that why the server needs to send a domain object to the client, the server can send just a command String (or any kind of data the client can parse), and the client can create domain object and execute a method on its side. So no need to send an object.
I don't understand the differentiation you are making. A serialized object is nothing more than data the client can parse. Only that the parsing (and serialization) is taken care of by the Java platform.
So, asked the other way around: why invest into dealing with sending command strings or parsing data and creating domain objects out of it, if you can just send an object?
SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
Consider Paul's rocket mass heater. |