@Itamar,
"..like duplicating the model too many times "
I am talking about best practice layers that in the future will help me to
maintenance the code in case of changing.. (pretty similar to GenericDAO
that we used to have with Hibernate..).
take the most simple scenario when I am creating ESService which Indexing
and querying the ES nodes.
So I thought about this:
Layer 1: Spring MVC Controller(Will "speak" with angular/JS/any other rest
requests)
Layer 2: ESService(Holding ESDao, Do some json manipulations, etc.. before
serving back to the controller)
Layer 3: ESDao to the actually executions and retrieve the raw results from
ES
"use the same structure for display as you use for indexing in ES"
What do you think? Any thing I should cut out?
@Danny,
I was suggesting that the approach of client code talking directly to a
firewalled/proxied search service is more productive than the client
sending an HTTP request to a server side
If I go this way than the logic will be duplicated within each client. what
about decoupling ??
Thank for your response,
ray.
On Sunday, July 13, 2014 12:04:27 PM UTC+3, rayman wrote:
I have simple web app containing the client side(Angular JS) and the
server layer(Spring,Spring MVC)
I am taking the simplest case of searching when a user have single search
input. behind the scenes I assume the JS will be send search request to the
server layers and wait for response.
I am interested how do you suggest to structure the layers on the server
end (containing the ES requests) using Controllers, DTO'S, DAO'S,
Async/sync requests, etc....
Any simple examples warmly welcomed.
Thanks,
ray.
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/73d391bc-b6b0-4768-a819-e80757f86b77%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.