1

Having looked at a lot of Dagger demo apps, it isn't clear to me where business objects are placed. In a typical three tier app you have ui, business layer and data access layer. MVP is essentially a three tier architecture.

Dagger deals with components and modules and I've seen demo apps place business logic in modules. But according to the MVP architecture, business logic belongs in the Presenter layer as this layers is suppose to act as bridge between the ui and model. Many of these demo apps have models that consist of nothing more than a class with public fields to store and retrieve data from.

Can someone clarify the proper way that this should be done.

Johann
  • 27,536
  • 39
  • 165
  • 279
  • if you had to remove either dagger or MVP from your question which would it be? Because it seems you think they are intertwined while in fact they have nothing to do with eachother – Tim Dec 21 '18 at 15:54
  • 1
    While they do not have anything to do with each other, developers do in fact combine these two and often place business logic in modules whereas MVP states it should be placed in the Model. So this issue should be addressed. Way too many apps I have seen putting business logic in areas that belong to Dagger. A module in Dagger is simply some mechanism that Dagger requires. Yet developers keep putting business logic there. I'm not saying it's wrong. Just saying that it's very confusing. – Johann Dec 21 '18 at 16:00
  • Can you provide any link to a project or tutorial that does that? Because I have never seen something similar. Dagger is a simple DI library, can't see how you would place business logic there if it solely purpose it is to inject dependencies into the real business objects. – dglozano Dec 21 '18 at 16:43

1 Answers1

6

Following clean architecture which was describe by Uncle Bob, all your code that contains business (domain) logic (rules) should be inside business layer.
For example we are developing mobile application for online ordering food / clothes. Does not matter.

Presentation Layer: (Consists of view and presenter)

- Presenter - handle view intents (button clicks, view rendered and etc), call business interactors, after received result from interactors, says to view to render current state of screen / layout.
- View - nothing more than render UI, keep view stupid, all your view logic should be in presenter.

Example case: In this layer you could check for example: user oped cart screen, your presentation layer makes request to interactor which returns cart items. If list is empty your view shows layout with title "Your card is empty", otherwise shows items list.

Business / Domain Layer: (Consists of interactor, helper classes and etc.)

Rule number one is keep your domain layer pure. If you using gradle you can use multi-modules with empty dependencies. Only language, rxjava cause it is almost standard of our time.

Example case: You need to validate user order information (delivery address, initial). All your logic should be here. Length check, regex validate and etc.

Data Layer:

Knows how to save, fetch, update, delete informations. All about persistence. In android cases: data layer could make http request via retrofit2, room orm and etc. Cache starts here.

If your app doesn't contain a lot of business rules, you could avoid business layer. It depends on the project.

Also important to use SOLID principles. It will make your architecture understandable, flexible and maintainable. Read more here.

Dmytro Ivanov
  • 1,260
  • 1
  • 8
  • 10
  • Can you explain what is " multiproject with empty dependencies"? – Chandrakanth Dec 26 '18 at 06:46
  • @Chandrakanth I mean multi module. Here is an more information. https://stackoverflow.com/questions/17536652/gradle-and-multi-project-structure – Dmytro Ivanov Dec 26 '18 at 09:03
  • What do you think about putting business logic in the backend versus in the domain/business layer on the app because you want to be able to develop for iOS and Android? Or should you simply duplicate it and just have a stupid CRUD backend? – Ludvig W Jun 28 '19 at 20:01
  • @LudvigW Sure, if you develop android/ios/whatever mobile apps it means almost all heavy logic should be concentrated in the backend because it is easy to share the same logic across apps. – Dmytro Ivanov Apr 17 '20 at 08:49