Чистая архитектура: одни и те же модели / объекты с разными уровнями - PullRequest
0 голосов
/ 28 ноября 2018

В моей настройке приложения Android с чистой архитектурой у меня есть собственный модуль Gradle для каждого слоя (данные, домен, презентация).У меня также есть собственные модели / сущности для каждого слоя, которые конвертируются из одного слоя в другой с помощью картографов.Это приводит к ситуации, когда у меня много классов данных kotlin, представляющих в основном одно и то же, но на другом уровне.Мне это не кажется правильным.

Простой пример:

Уровень данных - модуль библиотеки Android

@JsonClass(generateAdapter = true)
data class BuildingEntity(
    @Json(name = "u_id")
    val id: String,

    val name: String,

    val latitude: Double,

    val longitude: Double,

    @Json(name = "current_tenants")
    val tenants: List<TenantEntity>? = null
)

Уровень домена - Модуль Pure Kotlin

data class Building(

    val id: String,

    val name: String,

    val location: CoordinatePoint,

    val tenants: List<Tenant>? = null

Уровень представления Модуль приложения Android

data class BuildingModel(

    val id: String,

    val name: String,

    val location: LatLng,

    val tenants: List<TenantModel> = listOf()
)

BuildingEntity извлекается из API внешней сети.

Это хорошо отделяет каждый модуль друг от друга, но в моем приложении у меня есть много разных сущностей с вложенными структурами.В итоге я написал много классов и картографов данных kotlin.

Как мне это упростить?Могу ли я удалить класс Building и использовать BuildingEntity на уровне данных и домена?Просто конвертировать BuildingEntity в BuildingModel на уровне представления?

Я пытаюсь найти практические ответы, как люди решают такого рода проблемы, не заканчивая тем, что пишут тонны классов данных и картографов?

1 Ответ

0 голосов
/ 28 ноября 2018

В моем доменном модуле у меня есть мои модели как интерфейсы (Kotlin позволяет нам иметь значения внутри интерфейсов), реализации в модуле данных и никаких моделей в представлении вообще.

Взгляните на этот небольшой пример:

домен:

interface IUserModel {
    val id: String
    val name: String
}

interface UserRepository {
    fun getUserDetails(id: String): IUserModel
}

данные:

@Entity
data class UserEntity(
    @SerializedName("userId")
    override val id: String,
    override val name: String
) : IUserModel

class UserRepositoryImpl(val userDao: UserDao) : UserRepository {

    override fun getUserDetails(id: String): IUserModel {
        return userDao.getUser(id) //userDao.getUser returns a UserEntity
    }
}

представление:

class UserDetailsViewModel(val userId: String, val userRepository: UserRepository) : ViewModel() {
    val userData: LiveData<IUserModel> = MutableLiveData()
    fun getUserData() {
        (userData as MutableLiveData).postValue(userRepository.getUserDetails(userId))
    }
}

Нет картографов, нет тонны классов данных.

У меня есть пара проектов с этой структурой, и иногда требуется картограф (преобразование сетевых моделей в объекты базы данных), но многословность значительно уменьшается с использованием интерфейсов в качестве моделей в домене.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...