Is name Repository established forever? I always r...

# android-architecture

[ursus]

Is name Repository established forever? I always read it as a Dao basically. I'd call is Manager. Should I just get used to it?

[streetsofboston]

Those are just names. Repository, Dao, DataSource, UseCase, etc, whatever fits your project and your team is fine.

[ursus]

Sure, I'm just wondering if people also adopted the Repo naming. Feels weird, even in Spring repo = dao

[ghedeon]

yes, I think people just flow with it, I see Repository most of the time.

[ghedeon]

The common understanding is that DAO is closer to underlying persistence, but we're really comparing apples to apples here, imho they just come from different dogmas.

[Jérôme Gully]

For me, a Repository and a Dao isn't the same. The Repository is the "single source of truth" as describe in some documents, into it you manage how to return the data and from where you fetch them, returning from cache or server....

[Jérôme Gully]

If you use Room and follow the principle, you will quickly see that isn't the same.

[Jérôme Gully]

https://codelabs.developers.google.com/codelabs/kotlin-android-training-repository/#0

[ursus]

I mean sure but if you have read write and even network access in it, what do you put in use cases 😄

[ursus]

also this https://www.journaldev.com/21460/spring-repository-annotation

[ursus]

spring uses it as a dao

[Anastasia Finogenova]

I think in Android Repository is a data source. So you can call is DataSource. But why? If it is an established name . I never saw people calling it Dao in Android projects . Dao is a keyword for Room and other db interfaces. For Use Cases I think Repositoty can't be called UseCase. UseCase is called Presenter sometimes and should contain isolated business logic. Imo if you have networking there then you are doing something very wrong.

And for the Manager....after I read Clean Code and the part about naming I avoid such words as Utils/Manager/Helper. I think they are not evil of course but somehow it just came to me naturally after that I guess you can say subconsciously 😆😆

[Jérôme Gully]

Yes, sorry for my messages only focused on Android. I don't use Spring and don't now if the Repository make sens with it.
Even for Android, if you only have database acces (no network or other sources of data), Repository can be optional.

[Jérôme Gully]

+1 for avoiding "Manager/Utils/..." words. Not evil of course, but can lose other developers of your team with misunderstanding, what is the difference between a Manager and a Helper class ? 😂

[ghedeon]

@Anastasia Finogenova Repository is not a DataSource on Android. DataSource is a common name in Google's examples for abstractions on the top of Networking or Persistence that you inject in your Repository. You can say that Repository is a Facade for multiple data sources.

[Jérôme Gully]

For the Repository, I like the definition "single source of truth". If you already was lost in an source code with no certitude if the data must come from server or database, you know what I mean 😅

[ursus]

Well sure but isnt the goal of the "above android" part of the app be agnostic of everything? Therefore the naming should be consistent but, sure. I still like my Managers, its more versatile. Would you call a class that hosts a download queue and enqueues download requests and exposes the state, a DownloadRepository? Repo feels very limited what easily mentally maps to crud, imo

[Anastasia Finogenova]

@ghedeon yeah I agree that Repositoty is usually accessing DataSource to request data. And it is usually Networking implied as I see in the examples Dao will be for local db and DataSource for networking and Repository is a facade basically

[Anastasia Finogenova]

@ursus that is the issue people have with "Managers" versatile aka ambiguous or a pile of everything. But in your case it does make sense to call is DownloadManager but Uncle Bob's point was if you can't define one purpose for the class and call it View Helper and it is 1000 lines you are not writing clean code

[streetsofboston]

Very true, @Anastasia Finogenova. Class names such as Manager and Helper tend to indicate they do more than one thing. If they did one thing, their name would be different. 😀

[ursus]

Well issue is naming is hard, sure that could be a Downloader, but if that word didnt exist, what would you call it, DownloadDoer? i.e. slapping -er everywhere..

[ursus]

What about class that wraps android Intents and just gives you .openBrowser(), .share() .. what is that, Intenter? sounds silly

[ursus]

Call it IntentHelper and call it a day...

[Anastasia Finogenova]

I guess you can use extension functions now and avoid referring IntentHelper stuff now. There is also some reserved words for patterns like Facade. I also see the intent example being called IntentResolver for example. Of course we don't suggest "Intenter"🤷

[ursus]

You might have a point, but what my experience is, people just replace Manager with Repo, therefore youll have UserRepository.login(), etc, which is weird to me