Announcement Announcement Module
No announcement yet.
UI and Use Case centric service lock-in? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • UI and Use Case centric service lock-in?

    Need some help here. I am trying to justify the use of Roo for an application I am working on but the senior architect claims that it generates "ui and use-case centric services that can not be reused".

    Here is his full quote:
    "Roo looks like it may implement the classic JEE patten of controller-service-dao layering with dumb domain objects. This pattern leads to services that are UI and use-case centric as opposed to enterprise centric and hence has little or no reuse.

    A better approach would be to focus on proper domain modeling and rich domain objects. The business rules and logic is now in the domain object library and is therefore a powerfull and resuable asset. Now if roo can support that (without trying me to roo) then great."

    Can someone help me address this point? My application needs to provide re-usable services that can be exposed as web services down the road.

    Thanks in advance.

  • #2
    Roo doesn't implement a DAO layer, but places all persistence-related logic in the domain classes. It encourages a rich domain model and will also not create a services layer for you, although you're free to create your own (typically transactional) services that contain business logic spanning multiple domain classes.
    One of the features that Roo provides is that it allows you to edit and add code to your domain classes without getting in your way or restricting you b/o code generation limitations. The quoted comment is wrong about Roo-generated applications, and spending a couple of minutes with Roo and the resulting code will show you that; avoiding an anaemic domain model is what Roo strives for, just like your architects.

    Obviously the scaffolded web UI is 'UI-centric", but you could just as well use Roo without generating a web tier at all and then add 'enterprise centric services' yourself in one form or another (SOAP, REST, JMS, ...): in the end it's 'just' a Spring app. If you have a standard way to expose services you could even consider to create your own Roo add-on to support the process of creating the necessary artifacts.



    • #3
      Thank you for the information. That was VERY helpful! :-)