Topic
3 replies Latest Post - ‏2013-06-18T17:58:59Z by CBS3_Ian_Wilson
markobonaci
markobonaci
4 Posts
ACCEPTED ANSWER

Pinned topic FileNet CM 5.1 architectural decision - OO class hierarchy dilema

‏2013-06-14T22:47:30Z |

Hi all,
I'm in the process of designing FileNet architecture for a large deployment.
There will be around 400 types of documents.

I'm in disagreement with my colleague, who says that the hierarchical, object-oriented structure is not necessary and we can create a single document class that will have a "DocumentType" attribute, which we'll use for type distinction instead of built-in classes.

His arguments are:

  • regardless of class hierarchy, all documents end up in the same, DocVersion rdbms table, so there's no size benefit if you use class hierarchy (1 property template = 1 table column)
  • the whole security is going to be handled outside FileNet
  • other client's systems all have a single class so the integration is easier
  • programming through P8 Java API is easier since you don't have to deal with 400 classes


My arguments are:

  • easier to maintain FileNet system by adding new classes in inheritance tree
  • it's not possible to define different property values in different classes: default, min, max, choice list, hidden (image bellow)
  • if I split the data on two object stores for performance reasons, I'll need to have all possible attributes in each DocVersion table, so I could possibly hit database row size limit (btw, it's DB2, so for tablespace with 32K page size, row-size limit is 32677 bytes) in the future, as the client adds more property templates
  • that's the FileNet way and I've never came across any other approach in all the literature I red (which is a rather poor argument by itself)
  • it's not logical (which is also a rather poor argument by itself)
  • imagine writing OOP programs this way, what a nightmare that would've been (how exactly this argument maps to FileNet?)


Why is this the FileNet way?
What are my other arguments?
Which problems could arise that I cannot think of right now?

Thanks

Attachments

Updated on 2013-06-17T16:33:55Z at 2013-06-17T16:33:55Z by markobonaci
  • CBS3_Ian_Wilson
    CBS3_Ian_Wilson
    15 Posts
    ACCEPTED ANSWER

    Re: FileNet CM 5.1 architectural decision - OO class hierarchy dilema

    ‏2013-06-17T11:32:05Z  in response to markobonaci

    I can't comment on whether you need a hierarchy - that's a decision you only take once you have decided you need multiple document classes.

    The main design decision for identifying specific document classes comes down to the set of properties.  If each document type you mention would result in different sets of properties being used to store the meta data, then that would suggest you should be using multiple document classes.

    But if the set of properties is common for all document types, then just stick to one document class.

    ian-wilson.co.uk

    • markobonaci
      markobonaci
      4 Posts
      ACCEPTED ANSWER

      Re: FileNet CM 5.1 architectural decision - OO class hierarchy dilema

      ‏2013-06-18T17:31:45Z  in response to CBS3_Ian_Wilson

      Hi Ian,

      thank you for answering. Here's an additional question:

      That way, wouldn't I be designing for this particular moment in time, without thinking of future system expansion?

      How easy would it be to make changes in the system to accommodate for more classes in the future (partitioning existing docs and everything else on new classes)?

      • CBS3_Ian_Wilson
        CBS3_Ian_Wilson
        15 Posts
        ACCEPTED ANSWER

        Re: FileNet CM 5.1 architectural decision - OO class hierarchy dilema

        ‏2013-06-18T17:58:59Z  in response to markobonaci

        Yes, I agree with David, one bloated document class is not enough, but don't just create multiple sub-classes just for the sake of it - make sure you are designing actual "is-a-type-of" relationships to cater for future additional classes / properties.

        Moving existing documents into different document classes is possible, but messy, so I would avoid that if you can - try to get the design right initially.