Hakim Cassimally wrote:
I think you may be right. However I've spent barely 3 or 4 hours
looking at how to port an existing application to Moose/KiokuDB and I
think it may be an interesting thing to do. Our current logic uses DB
tables, with DBIx::Class, and some shims like ::DynamicSubclass. It's
powerful, flexible, fast, and very sophisticated for reporting.
But really, the more I think about it, our business objects would
benefit from living in a treelike structure: a "module" might contain
submodules with different business rules etc.. We can cope with the
existing logic, but the roadmap of new features contains a few things
that would seem to require massive re-engineering of our tables...
... and though I'm sure all this business logic /can/ be represented
in a relational DB, it might just require some deep thought.
With Moose, you just create your objects and the rules that tie them
together; then you plug it into KiokuDB and job done.
And when you change your object structure, you don't need to think
about how to model it, or how that will affect various other
relationships and queries. I added the bulk of one of the
"complicated" features I was worrying about representing with DBIC in
around 30 minutes.
At any time in the near future, I would be happy if you, or anyone, wanted to
share with me (most likely privately, and I can sign NDAs if needed) their
particular business rules, ideally in the form of a requirements document that
just says what you actually want to express in human terms, rather than saying
it in the form of SQL or Perl classes because it is very likely that those would
contain significant circumlocutions (and hence would add details that are
actually unimportant but I can't tell), and then I will try to formulate Muldis
D renditions of your business rules, and see if Muldis D can represent them more
faithfully or with less circumlocution than other methods, and if not then this
may point out things to improve in Muldis D's design; its fine to include the
SQL or Perl also as illustration, but separate requirements are important for
best interpretation of those; thank you. -- Darren Duncan
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
