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?

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

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

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

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....

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

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 😆😆

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.

@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.

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 😅

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

@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

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. 😀

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..

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"🤷

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