Results 1 to 3 of 3

Thread: UI and Use Case centric service lock-in?

  1. #1
    Join Date
    Nov 2009
    Posts
    28

    Exclamation 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. #2
    Join Date
    Mar 2005
    Location
    The Netherlands
    Posts
    121

    Default

    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.

    HTH

  3. #3
    Join Date
    Nov 2009
    Posts
    28

    Default

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •