Skip to content

Иерархия проекта оформлена с помощью псевдографики #6

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Oct 29, 2017
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
107 changes: 55 additions & 52 deletions practice/Practice_article.md
Original file line number Diff line number Diff line change
Expand Up @@ -72,58 +72,61 @@ https://martinfowler.com/bliki/CQRS.html<br>

В проектах с чистой архитекторой, чаще всего пакеты формируют по фичам или слоям. Примеры есть в статье http://www.javapractices.com/topic/TopicAction.do?Id=205.<br>
Примерная структура проекта может быть такой:<br>
-di<br>
---app<br>
---payments<br>
---operation<br>
-presentation<br>
---view<br>
-----payments<br>
-------PaymentsView<br>
-------PaymentsFragment<br>
-----operations<br>
-------OperationsView<br>
-------OperationsFragment<br>
---presenter<br>
-----payments<br>
-------PaymantsPresenter<br>
-----operations<br>
-------OperationsPresenter<br>
-domain (он же business)<br>
---payments<br>
-----PaymentsInteractor<br>
-----PaymentsInteractorImpl<br>
-----CurrencyHandler (вспомогательный класс для PaymentsInteractor)<br>
---operations<br>
-----OperationsInteractor<br>
-------rubs<br>
---------OperationsInteractorRubs<br>
---------RubsManager (вспомогательный класс для OperationsInteractorRubs)<br>
-------currency<br>
---------OperationsInteractorCurr<br>
---------CurrencyManager (вспомогательный класс для OperationsInteractorCurr)<br>
-repositories<br>
---payments<br>
-----PaymentsRepository<br>
-----PaymentsRepositoryImpl<br>
---operations<br>
-----OperationsRepository<br>
-----OperationsRepositoryImpl<br>
-data<br>
---network<br>
---db<br>
-models (по сути хранилище всех dto)<br>
---payments<br>
-----PaymentsModel<br>
---operations<br>
-----presentation<br>
-------OperationUIModel<br>
-----domain<br>
-------OperationsRubModel<br>
-------OperationCurrModel<br>
-----data<br>
-------OperationsRubNetworkModel<br>
-------OperationCurrNetworkModel<br>
```
project
├─ di
│ ├─ app
│ ├─ payments
│ └─ operation
├─ presentation
│ ├─ view
│ │ ├─ payments
│ │ │ ├─ PaymentsView
│ │ │ └─ PaymentsFragment
│ │ └─ operations
│ │ ├─ OperationsView
│ │ └─ OperationsFragment
│ └─ presenter
│ ├─ payments
│ │ └─ PaymantsPresenter
│ └─ operations
│ └─ OperationsPresenter
├─ domain (он же business)
│ ├─ payments
│ │ ├─ PaymentsInteractor
│ │ ├─ PaymentsInteractorImpl
│ │ └─ CurrencyHandler (вспомогательный класс для PaymentsInteractor)
│ └─ operations
│ ├─ OperationsInteractor
│ ├─ rubs
│ │ ├─ OperationsInteractorRubs
│ │ └─ RubsManager (вспомогательный класс для OperationsInteractorRubs)
│ └─ currency
│ ├─ OperationsInteractorCurr
│ └─ CurrencyManager (вспомогательный класс для OperationsInteractorCurr)
├─ repositories
│ ├─ payments
│ │ ├─ PaymentsRepository
│ │ └─ PaymentsRepositoryImpl
│ └─ operations
│ ├─ OperationsRepository
│ └─ OperationsRepositoryImpl
├─ data
│ ├─ network
│ └─ db
└─ models (по сути хранилище всех dto)
├─ payments
│ ├─ PaymentsModel
└─ operations
├─ presentation
│ └─ OperationUIModel
├─ domain
│ ├─ OperationsRubModel
│ └─ OperationCurrModel
└─ data
├─ OperationsRubNetworkModel
└─ OperationCurrNetworkModel
```

Разбивать только по слоям или фичам невсегда бывает удобно, поэтому гибридный вариант, когда внутри одного пакета слоя могут быть пакеты с фичами, вполне приемлим.<br>

Expand Down
108 changes: 55 additions & 53 deletions theory/Theory_article.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,60 +23,62 @@
Модели данных обычно представляют собой простые POJO, то есть только данные без какой-либо логики. Для упрощения все подобные модели лучше размещать в специальном пакете под названием "models" (можно подобрать более удачное название, чтобы не так созвучно было с понятием "model").<br>

Структура пакетов:
```
project
├─ di
│ ├─ app
│ ├─ payments
│ └─ operation
├─ presentation
│ ├─ view
│ │ ├─ payments
│ │ │ ├─ PaymentsView
│ │ │ └─ PaymentsFragment
│ │ └─ operations
│ │ ├─ OperationsView
│ │ └─ OperationsFragment
│ └─ presenter
│ ├─ payments
│ │ └─ PaymantsPresenter
│ └─ operations
│ └─ OperationsPresenter
├─ domain (он же business)
│ ├─ payments
│ │ ├─ PaymentsInteractor
│ │ ├─ PaymentsInteractorImpl
│ │ └─ CurrencyHandler (вспомогательный класс для PaymentsInteractor)
│ └─ operations
│ ├─ OperationsInteractor
│ ├─ rubs
│ │ ├─ OperationsInteractorRubs
│ │ └─ RubsManager (вспомогательный класс для OperationsInteractorRubs)
│ └─ currency
│ ├─ OperationsInteractorCurr
│ └─ CurrencyManager (вспомогательный класс для OperationsInteractorCurr)
├─ repositories
│ ├─ payments
│ │ ├─ PaymentsRepository
│ │ └─ PaymentsRepositoryImpl
│ └─ operations
│ ├─ OperationsRepository
│ └─ OperationsRepositoryImpl
├─ data
│ ├─ network
│ └─ db
└─ models (по сути хранилище всех dto)
├─ payments
│ ├─ PaymentsModel
└─ operations
├─ presentation
│ └─ OperationUIModel
├─ domain
│ ├─ OperationsRubModel
│ └─ OperationCurrModel
└─ data
├─ OperationsRubNetworkModel
└─ OperationCurrNetworkModel
```

-di<br>
---app<br>
---payments<br>
---operation<br>
-presentation<br>
---view<br>
-----payments<br>
-------PaymentsView<br>
-------PaymentsFragment<br>
-----operations<br>
-------OperationsView<br>
-------OperationsFragment<br>
---presenter<br>
-----payments<br>
-------PaymantsPresenter<br>
-----operations<br>
-------OperationsPresenter<br>
-domain (он же business)<br>
---payments<br>
-----PaymentsInteractor<br>
-----PaymentsInteractorImpl<br>
-----CurrencyHandler (вспомогательный класс для PaymentsInteractor)<br>
---operations<br>
-----OperationsInteractor<br>
-------rubs<br>
---------OperationsInteractorRubs<br>
---------RubsManager (вспомогательный класс для OperationsInteractorRubs)<br>
-------currency<br>
---------OperationsInteractorCurr<br>
---------CurrencyManager (вспомогательный класс для OperationsInteractorCurr)<br>
-repositories<br>
---payments<br>
-----PaymentsRepository<br>
-----PaymentsRepositoryImpl<br>
---operations<br>
-----OperationsRepository<br>
-----OperationsRepositoryImpl<br>
-data<br>
---network<br>
---db<br>
-models (по сути хранилище всех dto)<br>
---payments<br>
-----PaymentsModel<br>
---operations<br>
-----presentation<br>
-------OperationUIModel<br>
-----domain<br>
-------OperationsRubModel<br>
-------OperationCurrModel<br>
-----data<br>
-------OperationsRubNetworkModel<br>
-------OperationCurrNetworkModel<br>

3. Есть несколько вариантов трактования понятия "Репозиторий". Подробно можно почитать, например, [здесь](http://hannesdorfmann.com/android/evolution-of-the-repository-pattern). В Андроид-мире "Репозиторий" - это абстракция для получения данных, то есть она скрывает, с какого именно источника получены те или иные данные. <br>
Кроме того Репозиторий может внутри себя реализовывать логику кеширования данных и соответственно выдачи либо закешированных данных, либо данных с сети.

Expand Down