我们有什么：
该项目是一个与站点、本地数据库WPF交互并在用户界面中显示数据的应用程序。
工作示例：
该站点有一些类似主题的内容会不时更新。您需要“下载”这些主题的最新状态并写入本地数据库，我们称之为同步。同步后，我们可以快速搜索数据库、做各种笔记、加入收藏夹等，通过用户界面进行交互。
结构愿景：
该模型结果是一个，用于基础的模型，用于 MVVM 的模型。但是，我还想创建一个 API 层，它将与站点交互并返回模型实例。但是 API 也需要一个模型。
结果是 2 层（或 3 层？）- API 和数据库（+ MVVM）。使用一个模型。所以你需要使用贫血模型？还是最好将模型分开，为每一层制作自己的模型？
现在介绍与 VM 交互的逻辑。如果用户想根据条件获取主题，VM必须启动同步器，等待完成，然后才向数据库查询。将通过 API 接收主题的同步器（解析器）分开并在数据库中将它们更新为单独的类或将此逻辑提供给 VM-mothers 是否正确？
发生了什么：
- 与站点交互的 API 层
- 数据库层
- 连接 API 和 DB 的同步器
- 虚拟机通过同步器与数据库和 API 交互
- API、DB 和 MVVM 的通用 DTO 贫血模型。
使用分离数据和整体设计方法是否正确？
一种难以理解的可怕意识流。
您基本上拥有某个站点的桌面客户端应用程序，允许您从该站点获取数据、离线查看并添加一些元信息。所以这是我的标记...
我更喜欢一种方法，其中有模型（实体）和可以对这些实体执行某些操作的服务，即贫血。
模型（实体） 不要产生不必要的dto。这意味着“主题”模型（实体）对于数据库、站点客户端和视图模型将是相同的，除非另有要求。
数据访问层——一切都取决于它。我更喜欢将其视为外部存储。这意味着有一种存储库/存储，您可以从中获取或放置数据。他必须在他的外部层面接受精华，并随心所欲地将它们储存在自己体内。例如，分为两层——顶层处理实体，底层处理简单类型。
有很多实现选项，模型是否贫血取决于它。我不欢迎知道如何存储自身的丰富模型，但在 dto 中退化的模型也很糟糕，所以我的模型包含数据和一些阻止它直接存储的方法，inode 迫使我使用 dto（但在练习我比纯粹的贫血更麻烦）
该站点的客户端是一个包装器模块。在一个简单的例子中，这些是 1-2 个类，它们将网络请求隐藏在它们自身内部，本质上是它们的数据转换。在模块边界引入你自己的数据类型（并且可以编写一个额外的适配器/映射）只有在这个模块将在其他项目中重用或者你真的想要更多的模块隔离或者我们有一个干扰很多的 ORM 时才有意义. 否则我们违反了 YAGNI
View (WPF+MVVM) - WPF 渲染，MVVM 提供显示数据并将视图绑定到模型。MVVM 提供数据以显示并运行到数据模型或请求做一些工作，但本身不包含应用程序逻辑。他的工作是连接应用程序的外观和逻辑。尽管即使这样，视图模型还是很大胆，所以一些人向视图模型添加了控制器（MVVMC），它接管了与模型的通信。
同步是一种属于模型（不要与实体混淆）的服务，而不属于视图，因此它不作为视图模型的一部分存在。
所以我们有条件地获得了模块。这一切都像这样一起工作：
还有一些网站上没有的附加数据——注释、“收藏夹”标签等等。它们可以与“主题”实体分开存储，或者作为该实体的一部分（站点的客户端不会影响它不知道的那些字段）。分解是个太有争议的过程——我不喜欢数据库里有很多列，但是保存和减去一个图也懒得写了。
引入 DTO - 仅在必要时使用。DTO 或特定于模块的实体（或使用简单类型）允许更好的模块隔离……但是 YAGNI 要求您思考“我们需要它吗？”
尝试标记模块的边界，以便您只能使用它们。同时，模块的内部是隐藏的。即使您需要某种内部部分，也请尝试通过外观（模块边框）提供访问权限