Android多模块架构:域依赖于数据,反之亦然

gr8qqesn  于 12个月前  发布在  Android
关注(0)|答案(2)|浏览(118)

在Android多模块架构的例子中,有层依赖于数据的例子,也有域层依赖于数据的例子。
Android Developers site说:
域层是位于UI层和数据层之间的可选层。
它还显示了域依赖于数据的图片:x1c 0d1x
另一个article on proandroiddev.com说:
1.
域层是洋葱的最内部部分(与其他层没有依赖关系),它包含实体,用例和存储库接口。用例合并组合来自1个或多个存储库接口的数据。
最常见的错误之一是让应用程序由数据层/特定数据系统驱动。
域层不依赖于数据层。
并显示相应的图像:

那么你能描述一下哪种方法更适合Android多模块吗?为什么?

j8yoct9x

j8yoct9x1#

如果考虑到这两个问题都是正确的,与你想要实现的适当背景。
如果你想实现一个仅适用于Android的解决方案,那么Android开发者文档更适合你。如果你想创建一个针对多平台(Android、iOS、桌面)的项目,那么ProAndroidDev的架构更适合你。
另外,在阅读他们的文档时,我希望你记住他们的最终目标和背景。
在Android开发者文档中,数据层由实体和存储库类组成。这些类在Usecase类中是必需的,因此Domain层依赖于数据层。在此架构中,假设您仅为Android构建应用程序,因此不需要为存储库类创建抽象,因为它会增加复杂性。
在ProAndroid dev的文档中,假设您现在正在为Android构建应用程序,稍后您可能会引入其他平台,或者您现在只针对多个平台。在这种情况下,Repository类抽象变得更加重要,因为通过在早期添加它,您可以减少未来的bug/重构。在此文档中,为了实现上述目的,而不是数据层,域层现在包含Usecase、Entity和Repository接口类,数据层包含Repository Impl类。因此,域层不需要任何依赖关系,因此它不应该对其他层有任何依赖关系。
我认为在ProAndroid开发者的博客中,如果他们将包含Repositories的层称为Repository Layer而不是Data Layer,那么这种混淆就可以避免。在Android的博客中,他们将其称为Data layer,因为它包含实际的数据/POJO类和Repository类(负责管理此数据的类)。

zvms9eto

zvms9eto2#

我将尝试独立于Android做出回应,因为我根本不是这方面的Maven。从纯粹的设计概述:
需要注意的几点:

  • 在任何架构中都没有固定的层数。
  • DataLayer不仅仅是关于来自数据库的数据,它可以是来自应用程序外部的任何数据(API.)。你可以称之为Dependency来简化事情,就像Robert Martin在Clean Architecture中所做的那样。
  • 总是存在依赖关系,层只是一种抽象和识别事物的方式。我们尽量不太依赖数据,但总是存在依赖关系。但让我们让一些事情变得更容易。

我们在设计中尝试做的是创建范围(层,分类)来分离关注点并添加抽象。有很多架构试图以不同的方式将其放置到位,但目标是相同的:

  • 良好的分类/抽象
  • Dependency上的小耦合(框架和外部系统:数据库,API...)
  • 使系统更改更容易,并限制更改的影响

我同意Ashok的观点,这两个问题在一定程度上是正确的。这取决于你将遵循哪种架构:领域层通常是关于系统的核心,它意味着软件要解决什么功能和什么问题,你在这一层实现独立于外部系统、框架、应用层(终点,如何展示你的程序特性.)这就是为什么我们称之为领域层,一些开发模式或策略,如领域驱动设计,可能适合开发这种层,并给予更多的技术和选择,以成功地实现它正确或更干净。我建议看看它(尝试找到一个好的资源或只是购买埃里克的书,许多人在互联网上解释这个设计不正确)。
所以这一层将有它们的类(域实体,可能是服务.)在第二层DataLayer中被称为什么(我称之为扩展性=外部系统依赖性+框架扩展性)你的域层应该只依赖于来自这一层的接口。域层不应该给予对扩展性实现的兴趣。
表示层在开始使用域层时(可能是通过直接调用,或者通过API,它取决于应用程序),它不应该使它们的视图(UI)依赖于域暴露的类/对象的结构。表示层应该创建自己的类/对象,并转换域暴露的数据。这可以避免域中的更改破坏表示层。

注意事项:在前端与后端分离的设计中,另一个称为应用层的层可能包含向表示层公开域功能的端点。

对不起,这类问题很难简单回答。请不要犹豫,与我联系以获得更多的澄清。

相关问题