Should the reporting logic to extract domain data in a certain format reside in domain objects or separate reporting objects? The reporting logic needs to:

  1. select entities/data which match selection criteria e.g. date range
  2. apply data validation rules e.g. date range, boundary values, missing values
  3. apply type of reporting specific validation rules

    a. The rules will vary depending on type of domain object i.e. a certain domain object will require additional rules or different rule validation logic

  4. transform data in certain format

    a. Depending on domain object, number of fields may vary in the output

Solution Design

  1. Should there be parallel hierarchy between reporting classes and domain classes?
  2. The reporting classes will interact with domain classes through domain class interface
  3. A context object would be needed to create domain object specific validator objects so that report generator can have generic logic

Does this look like a good approach or am I approaching it incorrectly?

Class Diagram

  • 4
    Isn't a report just another type of user interface? – JeffO Jul 2 '14 at 18:15
  • @JeffO you are right. My question is if you have logic specific to report and that logic will not be needed anywhere else, how would you model that logic? Should the logic go into domain objects or should there be separate reporting objects? – jags Jul 3 '14 at 1:19
  • I think maybe that's what @JeffO is getting at. There are (if you choose to use them) already patterns around preparing objects for use in the UI, often by transforming a series of business objects into UI-usable objects. If that's the case, then oftentimes yes, there is a separate set of objects. And those may actually build off your existing business objects depending on your scenario. JeffO, care to comment further on what you meant? – J Trana Jul 5 '14 at 4:47
  • I guess what I mean is, if you had a data entry form that required some business logic to display a calculated value (concat(FName, LName)) even if this was the only place where that logic was needed, how would that be treated in your application? – JeffO Jul 6 '14 at 3:20
  • @JeffO If I am following correctly, does that mean we should keep that logic in say ApplicationDomain (or PresentationModel) object. Such logic will not go into pure domain objects, but the logic will also not go in UI layer. Such logic would go in Middle layer between UI and Domain, and this layer would be PresentationModel. Similarly, I should place my reporting logic. Am I understanding it correctly? – jags Jul 6 '14 at 4:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.