Woody88
Is ORM the only way or the right way to design and deal with data?
Hi guys so I have been trying to build is small library app - the app just will ultimately allow users to reserve study rooms or auditoriums. It will also allow users to book and expert(just a person that has a certain skill they need, like math…) to help them with whatever needs they have. The app reads a CSV file that has all the library branches from the city and it also contains all the rooms that each branch have.
Ok, now the real issue. Due to the new suggest way of building things in Phoenix 1.3 (context) I have been trying to build my little elixir app following the context rule. I originally decided to use processes to hold my states such User, Branch, Room, Availability, and Reservation. But, It felt like I was starting to rewriting ORM crud operations. Thus, I decided to find something that did not require me to use Ecto because I was getting really confused on where to put schema, models and so on. I found this repo Moebius, as I’m using it I found my defining functions such as from_model, to_model basically mapping DB to my structs. Why? Well, this is what I have always learned from java, .net, Ruby and jumping to Phoenix.
I would like to know, can I just create my app without relying on structs to define my data and just use… I guess modules to define how to transform my data or what type of operation can be done with the retrieve DB data?
Pretty what is the right way? Or what the advantages and disadvantages between ORM and Directly just querying to you DB without transforming your data to a model?(Ecto vs Moebius?)
Whats is the correct or approved way of designing when it comes to this subject?
If feel like I am lacking some basic knowledge here, can anyone help?
Thank you.
Most Liked
michalmuskala
Another important advantage of Ecto as a tool is that, as far as I know, it’s currently not possible to introduce, even by accident, an SQL injection vector using the query DSL - this is checked at compile-time.
OvermindDL1
The main advantage I see to using an ORM over raw calls is static ‘typing’ (at least making sure the names are correct) as I have a habit of mis-typing something and I like the compiler to catch me instead of getting a wtf SQL error later. ^.^
hubertlepicki
No, it’s not. Postgrex is pretty good on it’s own and not difficult to use. You can extend it’s functionality with type casting etc. to the level that can be very much all you need.
Check out: https://github.com/elixir-ecto/postgrex/tree/master/lib
But I’m not advocating you do that, esp. if you just start with Elixir.
peerreynders
In the other topic I mentioned the repository - it’s essentially a Façade which wraps your persistent storage access technology - whether it’s something as low-level as ODBC or high level as a relational mapper like Ecto. The only thing the context contributes is the boundary for the functionality of that (context’s) repository (which is necessary to support the capabilities of the context).
The more significant issue in terms of coupling are the data types (shape of data; structs) which are used to interface with the repository - for example if the repository returns and accepts types that are generated with the assistance of Ecto.Schema for use with Ecto.ChangeSet then the repository has failed to decouple the application from Ecto. On the flip-side a lot of the value that Ecto can provide is lost if the application is successfully decoupled - you’d essentially have to implement your own Unit of Work.
Another perspective is to simply, deliberately accept the coupling between, for example, Ecto and the rest of the context’s capabilities - provided that the context is small enough to be easily replaced in it’s entirety when the persistent storage technology changes sometime in the future.
hubertlepicki
I think in most cases, it’s going to be considerably more work.
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Build Elixir applications with speed and confidence.
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
Courses that'll move you from confusion to "Aha, now I get it!"