Oh that is nice, it really clean up schemas to the bare minimum.
kokolegorille
thiagomajesk
@pedromtavares I don’t find this to be true though. After all, the whole concept of virtual fields is to hold data that is not supposed to be in the database in the first place. But I think I understand the gist of what you meant.
Since you do this on a higher level (service), how are you dealing with cases where you consume data directly from the database, for example, a RESTful API? In the product I’m working right now, to avoid “abusing” contexts too much, we are implementing a serialization protocol that knows how to map/ build/ transform some of the fields to make it available in our schemas.
Thanks for the reply @sasajuric! This is a very interesting approach, but I have to ask: don’t your contexts get too big over time doing this? I don’t think I would be able to use this in my applications because we have more than one changeset to represent multiple states of editing a resource and I don’t think I’d like to have it all cramped inside just one module.
0
pedromtavares
Would you mind posting a few code snippets of this architecture?
From what I understood, you need to assign these extra properties on top of a database schema to serve it as a ‘decorated’ API, so I would tackle this by adding something like a Decorator service module, so you would have say a post = Repo.get!(id) |> PostDecorator.decorate(). You could then have that decorate method add these extra properties.
0
sasajuric
Author of Elixir In Action
When a context module grows large, we split it and/or extract some related group of private functions into internal private modules which are only used from within the context layer.
3
tfwright
In Rails it was common at a certain point to have projects where a ton of the “glue code” was in the models, but for the most part I didn’t find it to be too much of a problem, compared to something like business logic in controllers which was frighteningly common. I was actually more frustrated when it became “good practice” to keep models lean by adding an /app/services directory and stuffing that with as many arbitrary modules and classes (often with very little apparent reason for the choice) as possible, nested multiple levels deep, with key parts of the application flow buried somewhere within. No conventions, no explicit connections to the rest of the domain, just spaghetti code with a veneer of respectability (in OOP, the mistake of more objects == good architecture). Instead I found it much better to introduce namespaces that grouped models that had a lot of communication, and store glue code there.
That experience makes me leery of principles like schema modules should contain no logic not even changeset functions. But what I like about Phoenix contexts is that they encourage more thoughtful domain design that can make room for this glue code from the beginning, instead of exiling it to some catch all folder or arbitrarily attaching it to some specific “god” model. But at the end of the day I don’t see anything wrong with putting something like a “full_name” constructor in the schema, if it is only concerned with that schema. To me that’s its natural place in the domain, rather than with the glue code (unless it is only used for display purposes in which case I would consider just putting it in the view helper).
My first thought here is that this begs the question–what is the responsibility of a “translator”? Probably not dealing with request query params, sure, but joining two db columns into a single string? That sounds like translation to me. In any case it’s part of the underlying hard problem and as such there are no easy answers.
2
thiagomajesk
We have a Serializer and a Mapper protocol with this base implementations:
defimpl Serializer, for: List do
def serialize(data) do
data
|> Enum.map(&Mapper.map/1)
|> Jason.encode!()
end
end
defimpl Mapper, for: Any do
def map(data), do: data
end
If we need custom conversion logic, we implement a protocol for the target type we want to transform.
This was inspired by something we usually do in C# using AutoMapper to transform Models into DTOs.
The idea here is to eventually evolve this into a decorator or presenter pattern as you mentioned and is one of the things I’m doing in our codebase to help split logic that depends too much on the schema.
This experience you had is something that I can relate to. In the asp.net world, long before DDD was cool this is exactly what happened¹. What you described is how I see Phoenix contexts being abused tbh. In theory, you could make the interpretation that it’s a super layer that exposes everything else to the application.
¹In contrast, nowadays you’ll see a lot of codebases concerned too much with not “coupling” anything to anything else and this produces almost unmaintainable code.
I once worked on a project that for each new feature I had to create like 8 or 10 files (layers) with application services, domain services, infrastructure services, DTOs, mappers, etc.
1
hlx
In Programming Ecto there is a chapter called “Optimizing Your Application Design > Separating the Pure from the Impure” which basically says that pure functions (with no side effect) can be placed in schemas while impure (with side effects like database access) can be placed in contexts. This means that changesets, queries and multi’s can go in the schema and the rest in the context.
I really like this idea and I’ve been using it a lot and it works well for me, but after reading Saša’s comment I’m eager to try out putting changesets as private functions in the context for this current project I’m working on.
5
thiagomajesk
I haven’t read this book, but I was instinctively drawing this line for my side-projects. However, I wasn’t making this clever distinction of “pure” vs “impure” like you described.
I’ll certainly take a look at it. Thanks for the recommendation!
0
hlx
I highly recommend it.
After thinking about what @sasajuric said, I am definitely going to try out moving the changeset functions out of the schema to the contexts. After looking at Ecto.Changeset.prepare_changes/1 I realized that changeset functions can also become impure. That is not a big deal but one more reason to move them.
0