Announcement Announcement Module
Collapse
No announcement yet.
Organization of the package structure Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Organization of the package structure

    How do you organize your package structure in your application? Especially the service, business and persistence? I've less experience with enterprise applications.

    My example:
    at.test.Customer.bo --> My Business Objects and Hibernate-Mappings of the objects
    at.testCustomer.domain --> Service Interfaces and Implementiations of the interfaces. In the domain I also have my DAO/Persistence.
    at.test.Customer.ui --> User Interfaces

    Therefore it would be nice to know how you organize your packages to get ideas what can I do better. I know that the structure depends on the problem, but every program has the same basic-structure.

    thanks for advice
    markus

  • #2
    Excellent question. IMO, most developers do not pay enough attention and cannot justify their chosen package structure. Me included unfortunately

    FWIW, I use the following structure:

    com.mycompany.project (domain objects)
    com.mycompany.project.dao (DAO interfaces)
    com.mycompany.project.dao.hibernate (Hibernate implementations of DAO)
    com.mycompany.project.util (obligratory utilitys package)
    com.mycompany.project.web (general web objects)
    com.mycompany.project.web.controllers
    com.mycompany.project.web.views

    etc. etc.

    So you can see I structure by technology (controller, view etc.) and architecture (dao). You end up with a huge number of classes in web.controllers and web.views etc.

    I did experiment with not structuring by technology, merely by concept (e.g. use case) and it was a mess

    I *do* think it is a very important subject, and raises some very interesting problems, but it never seems to get the attention it deserves.

    BTW: I find http://www.clarkware.com/software/JDepend.html to be a really useful tool in analysing package structure.

    Comment


    • #3
      Originally posted by yatesco
      I did experiment with not structuring by technology, merely by concept (e.g. use case) and it was a mess
      I've been a big advocate of "package them by what they do instead of what they are", and it's been working well for me. To me, it's intuitive that classes (including interfaces) should be grouped around the logical concept they represent/implement. To name an (extreme) example, we don't see the JDK core classes organized as "java.interfaces", "java.abstractclasses", and "java.finalclasses", do we?

      A typical pitfall here is that people would start with the presentation tier, and organize the classes by use cases, which works out fine, but it becomes vague once it gets to the service tier. The problem here, IMHO, is that when people move from the presentation tier to the service tier, a lot of time they don't realize that, while the concept of "organize by use case" is still right, the _use cases_ themselves have changed. For the services, their "user" is something from the presentation tier. There might be more than one presentation use case (i.e. those normally considered use cases for the whole application) that use one same service use case, or there might be one presentation user case using multiple service use cases.

      Not realizing that, a lot of people tend to simply cut all the way through all the tiers vertically when organizing classes, which natually would cause some service classes around the same logical service to be put into different packages, or some other messy situations.

      Comment


      • #4
        I think I agree with what you are saying, but I don't get what point you are making by listing "java.interfaces", "java.abstractclasses" etc.

        I was discussing two different approaches, technology driver (com.x.y.z.web, com.x.y.z.dao etc.) or use case driven (com.x.y.z.booking, com.x.y.z.booking.create) etc.

        Comment


        • #5
          Originally posted by yatesco
          I think I agree with what you are saying, but I don't get what point you are making by listing "java.interfaces", "java.abstractclasses" etc.
          It was supposed to be an analogy to technology-oriented packages like:
          com.foo.bar.controllers
          com.foo.bar.dao

          While it's an extreme analogy, the essence is the same - interfaces, abstract classes, controllers, or dao are all technological terms that don't have to do with any logical perception on the application.

          Comment


          • #6
            Well I think there is a difference

            daos, web tiers etc. *are* conceptual layers, interfaces etc. are much lower. Kinda talking about carparks and shopping malls versus bricks and cobbles

            Just to be pedantic

            Comment

            Working...
            X