logic in handlers
Closed this issue · 3 comments
It's your favorite person again! lol
This may be something that's personal preference, but curious where you store most of your business logic? Are you doing most things in your handlers or do you store logic in your Objection models?
For example, with my other project, the vast majority of my logic lies in my models -- making the handlers very light.
Again, just trying to weed out some best practices. I realize there's many ways to do things, but it's always good to hear from others!
If I had to summarize– models, then server methods, then route prerequisites, then handlers. I like keeping my models fairly database-oriented, especially when using objection, which is so close to "the metal." Ideally (but not always) I wrap business logic related to fetching data in server methods. That's nice because the methods are 1. monkey-patchable for testing, and 2. trivially cacheable via catbox ( 😍 ). Then sometimes I'll use route prerequisites to keep data-fetching outside of the handler (bearing in mind that pre-reqs and handlers look identical, and what was once a handler can very easily be pulled-up into a pre-req). The handler then has everything it needs to perform the final touches– it aggregates the fetched data, performs any critical actions, and applies the biz rules to the results.
I don't think this is necessarily so cut-and-dry, though. I know my practices vary a lot. Did you ever work with ruby on rails? I recall the "fat model, skinny controller" mantra especially from working with that framework. I think there's truth there– the model has a big responsibility of only performing "valid" changes to the database, and that often requires biz logic in the model. Other biz rules, like enforcement of ACLs, might be better left to controller-like things that can better see the "big picture"– request extensions, handlers, server methods, pre-reqs, etc. I certainly would prefer one controller calling four models rather than four models calling each other. What has your experience been? What's type of logic is typically going into your models?
I'd agree that it's not so cut and dry. In my other project, the vast majority of my business logic was part of my models. However, I can see pros and cons to moving that logic elsewhere. Server methods and route pre-reqs are something I had no idea existed, so it's probably worth investigating to see how that may change things for me.
If you have an example of how you string things together, I'd love to see it!
I don't have any good public examples right now, but when we create the website for hapi pal that should be a decent example to check-out!