求解，这个功能属于Repository和Serivce中的哪一种？

[张天星]

有两个表：
Folder
{
ID,
FolderID,
Name,
}
Book
{
ID,
FolderID,
Name,
}
我将其取出来，组成一个临时表，写在ViewTree中。
Tree
{
TreeID,
Type,
Path,
Name,
ID,
}

Class TreeControl
{
List<Tree> Tree{get;set;}
//在这里中转TreeView控件和数据库的操作。
UI上出现了拖动事件，改变了文件夹或者书籍的位置，路径等，将拖动的key返回这里，取到对应的数据之后，去数据库中操作。
需要刷新数据的时候，UI也命令到这里，这里再转到数据库中刷新获取数据。
选中了某个TreeNode的时候，也是发到这里，然后这里根据TreeID获取Type和ID，判断点击的是文件夹还是书籍，是列出所有书籍或者列出所有章节，这里再控制另一个UI如EditText去显示内容。
反正UI所有的操作，都从这里中转，
那么这个类，是属于Repository，还是Serivce
}

[以专业开发人员为伍]

哪一个都不是。基本三层架构是 UI 表现层设计与所谓的后端分离，而你满脑子只有最底层。

[以专业开发人员为伍]

如果一定要“猜”，那么我们可以说不同系统层之间肯定是通过通讯手段来连接的。但是这并不是说凡是通讯都用一句“属于Service”来代替技术了，因为每一层都必定跟其它层有通讯实现，前端的通讯代码跟服务端的通讯代码肯定是不同的。要是搞不清楚自己在设计前端，满脑子只有“增删改查”，那么你说的 Service 概念肯定也不是前端的 Service 网关了。

[圣殿骑士18]

更像service

仓储更像数据的 标准化 存取。如果你有非存取的业务方法，那当做仓储就不合适了。


==========
欢迎关注微信公众号 “产品技术知与行” ，打造全面的结构化知识库，包括原创文章、免费课程（C#，Java，Js）、技术专题、视野知识、源码下载等内容。
最新文章：解读经典《C#高级编程》 第四章之 泛型的原理 https://mp.weixin.qq.com/s/3264VdbzqXWt7vn19ARrPQ

[以专业开发人员为伍]

纠结每一个业务 Model 来搞所谓的“增删改查”胡乱仓储代码集合，实际上大多数情况下是花画蛇添足的。假设你那么注重表现层跟后端封层独立，那么你的业务逻辑层直接调用一个数据库引擎驱动（一个通用的DAL）框架就行了，没有必要将微小的所谓业务逻辑按照“增删改查”再来反过来裹起来。持久化层框架就是去研究持久化层，是在 BLL 业务建模之前就搭的框架，这样你就能独立地做好数据库研究。现在来搞“竖井式思维”，其实不管你是从哪一个方向去理解技术分层，都失去了结构解耦的根本灵活性。

[以专业开发人员为伍]

你写个简单的 Model 定义，你可以用在各种框架驱动中，例如 DAL 层框架可以通过类似

var query = myDbContext.Query<ABC>(......);

来查询，那么请问这里到底是简单的 Model 定义是 DAL 还是人家在你写程序代码之前就发布的通用的 DAL 框架系统是 DAL 呢？ 实际上你自己写所谓的“怎删改查”，再把凡是跟增上改查的代码简单包装一下的代码纠结在一起，高什么“仓储”是没有必要的多于设计。应该把精力用在业务服务层设计上，并且直接从 BLL 层代码直接调用 DAL 层代码。没有必要太技术化。

[正怒月神]

肯定不是仓储Repository，可以算放在service中把。 但是我个人感觉更贴切的，可能是一个领域模型性质的viewmodel，

[以专业开发人员为伍]

表现层会有一个轻量级的“网关”（或者其它叫法）来调用业务逻辑服务功能，但是这是分不同层的。当你研究表现层，你就是在表现层。不要把后端的什么数据存储、远程服务直接作为前边万化的表现层的设计。

[正怒月神]

但是，你并不需要特别纠结这个问题。只要不在dal，那就问题不大

[以专业开发人员为伍]

引用 楼主 张天星 的回复:

//在这里中转TreeView控件和数据库的操作。

不理解基本的三层概念的人通常都是这样，有些工作了15年以上的人也是如此。因为初学编程时，都是没学过多少前端，而对于“增删改查”感觉特别高大上，所以容易接受所谓“一切需求、程序设计都是由数据库表中的数据增删改查操作而中转”的说法的毒害。 真正的产品设计通常都是分层的。比如说移动电话的基本功能设计不是以什么语音包 insert 到移动公司的关系数据库、然后再由几十亿的手机去 select 操作来描述的，真正的前端产品设计到了与业务逻辑层的通讯机制，就结束了。表现层跟业务服务层分离。后台处理通用服务和业务逻辑，前端处理各种设备上的用户交互逻辑操作，而不是满脑子只有底层。

[以专业开发人员为伍]

界面设计的数据结构模型跟跟底层的数据持久化模型差别很大。例如你的界面有“查询条件对象、查询结果对象”的Model 定义，它可能对应于后端的8个数据库表，甚至可能还有一些信息根本不是从数据库表里增删改查而来的，但是前端 UI 层都要作为基本数据 Model 而从业务服务层灵活地查询到。 前后端分离，你实现一个很棒的产品时你就是以前端为王来设计灵活的富有创意的前端界面的，怎么能把过多的精力和时间纠结在底层增删改查上？！

[以专业开发人员为伍]

真正的大产品（哪怕是用几天开发出来的价值几十亿的产品），前端都是设计到了与业务逻辑服务层的通讯协议接口规范，就可以了。前端会千方百计地重复使用、灵活组合后台接口调用，方便用户使用。 例如用户在界面上创建一个目录，然后把多个内容拖入这个目录，然后点击一下“目录刷新”按钮，那么整本书里边的所有目录可能就自动重新排版其索引编号和缩进参数了，即使电脑断电了、之后再重新开机，之前按了“目录刷新”时的自动保存内容也会出现。那么这个操作跟后台用没用数据库没有直接关系（后台可能直接调用出版社的面向业务服务的接口）。 实际上你的问题是将技术知识的目标检验点围绕在前端，但是你满脑子却只有底层知识。

[张天星]

引用 13 楼 以专业开发人员为伍 的回复:

界面设计的数据结构模型跟跟底层的数据持久化模型差别很大。例如你的界面有“查询条件对象、查询结果对象”的Model 定义，它可能对应于后端的8个数据库表，甚至可能还有一些信息根本不是从数据库表里增删改查而来的，但是前端 UI 层都要作为基本数据 Model 而从业务服务层灵活地查询到。

前后端分离，你实现一个很棒的产品时你就是以前端为王来设计灵活的富有创意的前端界面的，怎么能把过多的精力和时间纠结在底层增删改查上？！

我现在就是一个三个子窗口（Tree目录，Edit文本区，ListView章节区），通过Penal放到同一个FormMain主窗口上。
Tree上点击之后，要分析点击的是文件夹还是书籍，然后通过事件传给FormMain，FormMain再分别去控制Edit和ListView显示内容。
同样的，ListView点击某个章节之后，也是事件传回FormMain，FormMain再去刷新Edit的内容。
现在主要是两个问题，UI中代码有点多，想要修改下。
我本来是想解释我为啥要这么修改的，可是想着想着，我好像有点晕了，我再想想。。。

[wanghui0380]

那本书最大的问题是提出了“领域”概念
但到底撒是领域，怎么划分领域，他没讲。
前一半为了解释好处，给的例子，其实来源与“故事卡”和“测试用例卡”，但撒是领域？依然是浆糊

后一半强推仓储

结果是前面只知道领域好，怎么做不知道。后面是其实无关领域，但是别人只看的明白这块，具备可复制性，所以管他是不是领域，我复制这个仓储就代表我是最NX的做法DDD，可惜，可叹。那本书真正的价值在前半本，不在后半本。

[wanghui0380]

比如你实际描述的也是“用例卡”的描述

展示什么？什么操作，效果是什么？条件是什么

[张天星]

引用 16 楼 wanghui0380 的回复:

那本书最大的问题是提出了“领域”概念
但到底撒是领域，怎么划分领域，他没讲。
前一半为了解释好处，给的例子，其实来源与“故事卡”和“测试用例卡”，但撒是领域？依然是浆糊

后一半强推仓储

结果是前面只知道领域好，怎么做不知道。后面是其实无关领域，但是别人只看的明白这块，具备可复制性，所以管他是不是领域，我复制这个仓储就代表我是最NX的做法DDD，可惜，可叹。那本书真正的价值在前半本，不在后半本。

是 领域驱动设计 软件核心复杂性应对之道 那本么，我还没看完，看不太懂中。。。

[MWR_ma]

求解答，谢谢

[MWR_ma]

[非专业开发Five]

你自己把仓储的表拆掉，然后糅合业务一起做了一套新业务，你问我这是仓储还是服务？？？这不就是你拆了仓储做的服务吗？ 所以往本质说是这个类，是属于Serivce，用于操作Repository的Serivce。 你的描述你就是这么做的。

[Csdn技术大神]

属于service，看你自己怎么定义了

[张天星]

引用 21 楼 胖叔叔写代码 的回复:

你自己把仓储的表拆掉，然后糅合业务一起做了一套新业务，你问我这是仓储还是服务？？？这不就是你拆了仓储做的服务吗？ 所以往本质说是这个类，是属于Serivce，用于操作Repository的Serivce。 你的描述你就是这么做的。

多谢，过了几个月，慢慢理解了一点，DDD好头疼。。。。