I've gone back to the simpler approach you suggested where I have a module 
- UserStore that exposes the required functions and uses an Ecto.Repo 
internally.

Thanks again for the feedback.

On Sunday, 12 June 2016 22:06:13 UTC+3, José Valim wrote:
>
>
> To be clear, this is not about swapping out Ecto.Repo for another Repo 
>> implementation, so perhaps repository is not the best name. Its about 
>> having a behavior for your data entity that is satisfied by a concrete 
>> implementation that uses Ecto and another that could use a List.
>>
>
> I understood that and I wrote my original e-mail with exactly that in 
> mind. :) When you say "having a behavior for your data entity that is 
> satisfied by a concrete implementation", it still feels like you are 
> applying patterns from other paradigms and platforms without taking into 
> account the options provided by Elixir.
>
> Again, if you want to replace an implementation that uses Ecto by another 
> that uses a list, I would specially handle those cases by defining a proper 
> behaviour instead of simply having it as a default.
>  
>
>> Performance, especially within tests is not as much of a concern as 
>>> simplicity and I would argue that for the same reason you would have an 
>>> in-memory Twitter client, you could have an in-memory repository within 
>>> your tests.
>>>
>>
> The biggest point about replacing Twitter is to avoid an external 
> dependency you can't control in your tests. Otherwise your tests will fail 
> for reasons beyond your control. Unless the whole purpose of your 
> application is to integrate with Twitter, I wouldn't compare it to my data 
> layer.
>  
>
>> I think this is an approach that could have the same result, keeping the 
>>> underlying queries and Ecto interactions outside of the controllers (and 
>>> other layers where we want to control how the data is accessed).
>>>
>>
> Right and that's what I am trying to say. You don't need the "repository 
> pattern". You need modules and functions. Organizing everything into 
> patterns that are tied more to the structure is going to constrain you in 
> the long term. I realize I am repeating myself so I will refrain from 
> commenting again. All of the warnings were in the original e-mail. :)
>

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-talk/aee8ea70-db7f-489e-a67d-03afaed2925c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to