--- In [email protected], [EMAIL PROTECTED] wrote: > > Yes indeed, :-) > > My very best regards, > Pete Amiri
(I copied your previous comments here...) > I have a problem with such implementation. I honestly think that this is an anti-pattern ;-). You aren't alone in thinking that... the InfoQ article posted by Rob shows reasonable arguments on both sides: http://www.infoq.com/news/2007/06/entity-services > > Reasons; > > 1- Information / data decoupling is totally ignored here (tight coupling data elements change). Actually, I see the entity service as a strong solution for data abstraction and decoupling. The client doesn't know or care where the data physically resides, and the data is rationalized into an information object, hiding the back end complexity and physical distribution. > 2- Abstraction of business processes (what if your processes change). The idea is that business processes manipulate the business information exposed via entitiy services. There is some question about how much logic is placed in the entity service versus a layer just above it. But only logic that is intimately tied to the entity should be placed in the entity service (lifecycle rules, validation, etc). Processes can then manipulate entities, along with the other functions they perform. This seems to me to be a very desirable and appropriate positioning. > 3- This implementation has a major security risks, and possibly legal liabilities. Not sure I see this, other than to say security/access control has to be implemented properly regardless of implementation strategy (service oriented or otherwise). > 4- I can not find any justification for writing such a service. other than waist of network bandwidth and CPU cycles. I believe this leads to agility, reuse, and long-term efficiency of IT. That's really an SOA argument and whether you buy into it. -Kirstan
