| Architecture best practice? [message #1696373] |
Tue, 26 May 2015 07:40  |
 Jeremie Bresson
Messages: 1252
Registered: October 2011 |
Senior Member |
|
|
I have seen this pattern in several projects, and I wonder what the recommended practice is.
You get from an external service a structured object.
Depending on the technology (XML, Webservice, EJB, ...) the form of this object is different, but I my opinion the big picture is always the same. You can imagine a Graph of POJO (MyBean containing a lot of data, in particular lists of other beans and so on).
This object contains data for several operations:
* Initial population of the Form [loading the form with data].
* In case of a wizard / workflow: the MyBean instance contains data for multiple forms (each step)
* Provide some values for some SmartField (Data for the LookupCalls is contained in the object)
* Fulfill some business logic (fields in the form are enabled/disabled or mandatory/not-mandatory depending on the data)
* ...
The question is: given the object in the server, what is the typical approach to implement all this operations?
I have seen two approaches:
1/ Add a Variable containing the MyBean object in the form
The object instance is transferred to the client.
The FormData is quite empty, because field mapping occurred on client side (directly from MyBean to the several scout fields).
LookupCalls are implemented as LocalLookupCalls, fetching the data from the variable.
Field business logic (enable, visible, mandatory) checks the values in MyBeans.
The Scout Client has a dependency to the jar containing MyBean.
2/ Cache the Object in the Server
The other approach consists of caching the MyBean object in the Server.
The ProcessService maps the value from this object to the FormData.
The LookupCalls call LookupServices that retrieve the values from the Cache.
The necessary information requested by the business logic of the fields are packed as variable of the form and also mapped by the process service.
In my opinion, the difficulty in this case is due to the cache in the scout server (definition of IDs for each form, cache invalidation and so on).
----
Is there another approach?
What is the recommended pattern?
Thank you in advance for your ideas...
.
|
|
|
| Re: Architecture best practice? [message #1696382 is a reply to message #1696373] |
Tue, 26 May 2015 08:57  |
Daniel Wiehl
Messages: 1
Registered: May 2016 |
Junior Member |
|
|
|
I would say, that very depends on the requirements you got. Typically, such data is imported into your application and persisted. So you would provide a webservice provider or subscribe to a topic to get that data. In turn, that external data is normalized and it is transparent to your application, meaning that you do not have to change LookupCalls or even Forms. However, your proposed solutions are both practicable, there is no right or wrong way to go, but depends on your requirements. In my opinion, I would keep the client flat, meaning that any transformation should done on server side.
|
|
|
Powered by
FUDForum. Page generated in 0.03389 seconds
] 
Search
Help
Register
Login
Home
