AB Data

智能手机目前是该系统的唯一组件。它允许访问各种数据源，例如 GPS、互联网资源、地址簿、照片和日历，以及将信息存储在本地数据存储中。该应用程序可以分为三个不同的方面：各个层、各个功能模块和动态方面。

in|Forming 的分层架构
表示层

表示层遵循模型-视图-控制器架构，这迫使表示层的职责分离为数据模型（模型）、表示（视图）及其控制（控制器）。

业务层

应用程序的逻辑是在这一层实现的。 in|Forming 应用程序专注于解释和处理收集到的数据。

数据访问层

我们的应用程序的数据管理架构由几个层组成：

最底层是数据库。这是由核心数据框架管理的，它将数据库 奥地利消费者电子邮件列表 的实体关系模型中的实体映射映射到我们应用程序的模型类。
数据访问层是下一层，由DatabaseContext 和DALContext 组成。这里我们定义了用于存储各个模型类的 CRUD 操作（创建、读取、更新、删除）。此外，数据访问的真正实现和方言是从通用访问方法中抽象出来的，因此更容易用其他实现替换底层组件（例如数据库）。
例如，MongoDB 使用 find() 方法，EntityFramework 使用 get() 方法，Coredata 使用 fetch() 从数据存储中读取记录。

通过实现 CRUD 方法，可以与所使用的数据库和所使用的框架解耦。

模型

对象模型是跨层使用的。该模型的焦点是用户：

相册：用户可以拥有多个相册，每个相册包含多张照片。
联系人：它可以有一个或多个联系人，每个联系人可以有多个电话号码或地址。还可以将照片分配给联系人。
日历：此外，用户可以拥有各种日历，其中存储事件和存储可分类的提醒。它们还可能与文本挖掘确定的活动相关。
位置：用户可能有一个或多个位置，可以通过多种方式确定；
1. 照片的 GPS 坐标，
2. 日历条目和已存储地址的联系人。
活动：活动也可以分配给日历条目或特定位置。在某些情况下，甚至可以根据访问的位置推断活动。
子系统和模块
还可以从功能的角度来看待系统架构。该应用程序根据功能方面进行划分。

用户数据管理

UserDataManagement 内有管理器组件 LocationManager、PhotosManager、EventManager 和 ContactsManager。这些管理器的任务是通过其接口读出分配的组件。数据通过 DataInterpreter 在组件之间交换，并且这些组件之间存在各种依赖关系 - 例如，事件管理器提供有关联系人的信息，因为他们可以参加事件，而照片管理器从照片中读取 GPS 数据。这些依赖项必须由 DataInterpreter 组件管理。

用户数据建模

UserDataModeling 子系统负责处理通过 UserDataManagement 子系统检索的数据并将其存储在自己的数据结构中。用于此目的的 DataAccess 和 DataStorage 模块也使数据稍后再次可用。

用户界面

控制器组件通过数据访问组件读取数据。然后将读取的数据显示给用户，然后用户通过 View 组件与应用程序进行交互。输入处理发生在控制器组件中。

动态视图
in|Forming也可以从动态的角度来看待。从各种数据源收集数据是一个使用 CronJob 进行处理的重复过程。此作业在|Forming 运行时第一次启动，然后每 24 小时运行一次。其主要任务是保持数据存储与智能手机的可用数据同步。