Implemented in a way that separates the behavior that we want to express (entities) from the persistence layer (repositories and database). This design helps keep the interface of our objects small and therefore keeps them fast and reusable.
Perhaps we should remain ORM/REPO agnostic and add generators for different libraries?
At the moment, I think this is the best we can do until we discuss technical details.
It's actually pretty interesting that there's no built in model. This doesn't have to be another MVC. Having it handle routes, controllers, views, middleware, etc.. is quite a bit already. Being able to just plug in your own way of handling models and other business logic type stuff would be nice. Maybe there could be a separate shard for a "amber" type way of handling this stuff, but by default not in the amber shard.
That being said, seeing how the router is inspired from Phoenix, I though I'd find Crecto in there too. As long as it is easy to swap parts, I think that an "all-in-one" opinionated model makes sense (even if I had a different opinion on the ORM :wink:).
@oz We are considering to support Crecto for a Repo pattern type of models and Granite/Jennifer for Active Record Pattern with generators we still thinking about this one
Here is the example app created by @fridgerator for using crecto with amber:
https://github.com/fridgerator/amber_crecto_example
I am going to close this since we support granite and crecto. We can open a new ticket if someone wants to add jennifer.
Most helpful comment
It's actually pretty interesting that there's no built in model. This doesn't have to be another MVC. Having it handle routes, controllers, views, middleware, etc.. is quite a bit already. Being able to just plug in your own way of handling models and other business logic type stuff would be nice. Maybe there could be a separate shard for a "amber" type way of handling this stuff, but by default not in the amber shard.