[求教]三层设计中父实体中包含子实体如何设计三层引用关系?

[煮吧姐]

如下图


三层设计中如此的官方设计,出现一种情况是 当父实体中存在 子实体的情况,需要动态获取无法操作.

[煮吧姐]

为把问题描述的更清楚重新画图

[以专业开发人员为伍]

model 本来就应该嵌套实现。 有的人说 model 跟数据库表一样，那纯粹是误解。现在大多数关系数据库表只可能是一个二维表，表中记录字段不能嵌套其它对象。而 Model 是为了跨层传递对象用的，自然就是可以是嵌套的数据结构。所以 Model 并不对应一个个数据库表。从 Model 如何对应各个数据库表，那是 BLL 代码中去具体操作 DAL 的事情，而 BLL 对外输入输出参数使用 Model，表现层不关心数据库问题。 所以说，所谓“三层结构”中，你的远程调用 BLL 的接口需要获得什么 Model 就返回什么实体对象。一个 Model 可能对应2个数据库、2个其它 SOA 服务，8个数据库表，这都在一个 Model 中概括。这才叫做 Model。 那种以为数据库表决定 Model 的人，最后总是给用户说“你要是需求改变了，我就得重新设计软件”，结果消极怠工、只能做点小 OA 软件，做不了大软件，不敢承担需求前边万化的项目。就是因为他满脑子只有数据库表概念，而没有真正的 Model 概念。

[大鱼>]

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

model 本来就应该嵌套实现。 有的人说 model 跟数据库表一样，那纯粹是误解。现在大多数关系数据库表只可能是一个二维表，表中记录字段不能嵌套其它对象。而 Model 是为了跨层传递对象用的，自然就是可以是嵌套的数据结构。所以 Model 并不对应一个个数据库表。从 Model 如何对应各个数据库表，那是 BLL 代码中去具体操作 DAL 的事情，而 BLL 对外输入输出参数使用 Model，表现层不关心数据库问题。 所以说，所谓“三层结构”中，你的远程调用 BLL 的接口需要获得什么 Model 就返回什么实体对象。一个 Model 可能对应2个数据库、2个其它 SOA 服务，8个数据库表，这都在一个 Model 中概括。这才叫做 Model。 那种以为数据库表决定 Model 的人，最后总是给用户说“你要是需求改变了，我就得重新设计软件”，结果消极怠工、只能做点小 OA 软件，做不了大软件，不敢承担需求前边万化的项目。就是因为他满脑子只有数据库表概念，而没有真正的 Model 概念。

正解，估计是被代码生成器给套住了

[以专业开发人员为伍]

引用 2 楼 sunwork888 的回复:

有非常大的关系,看来我的表述不明确. 我想表达的意思如图,实体类被三层引用了. 但实体类中的 流程表实体为数据中的父表,其中有一个日志子表,在程序编写中,为了便利编写,通过父实体增加属性的方法获取子实体对象. 但如此使用需要 实体类引用 DAL或BLL层调用底层方法才可以实现.

这样你就根本没有认真分层，你的实体类干了业务的功能，这还叫做实体类？这种所谓的实体类根本不应该设计存在，就不用在讲什么编程上的引用了。

[正怒月神]

两种方案 1 要么设置实体之间的关联关系。也就是主外键关联 2 要么 在业务逻辑层去实现他们的关系。

[以专业开发人员为伍]

实体类是“失血的”，它顶多有点纯计算机的——最低级的——计算代码。它不可能代替 BLL 业务功能。 DAL 应该是纯粹的数据库操作，甚至你可以用 SQLHelper 这类来作为 DAL。而不应该写任何业务功能。因此实际上为了快速开发，你可以完全不用开发任何 DAL 代码，就用 EF、ADO.NET 等等现成的数据库层驱动作为 DAL。你不需要再做简单无什么作用的——薄薄的——DAL 封装。 只有 BLL 层才写业务。假设一个学校下面该有多少班级，班级里面该有多少老师和课程，这在业务功能中控制。DAL 被 BLL 调用来增删改查数据库。 DAL 里边不能写业务功能，而仅仅针对数据库系统来封装最低级的数据库引擎功能的！ 至于说 Model，是最干巴巴的数据。也就是

public class A
{
    public string Field_1{get;set;}
    public int Field_2{get;set;}
    public B[ ]  Field_3{get;set;}
} 

这类失血模型，不但 Model 不可能与数据库引擎关系，也不可能与业务功能操作有关系。

[以专业开发人员为伍]

引用 3 楼 sunwork888 的回复:

寻找解决方案中发现坛子中有使用委托的解决办法,

人家是表现层跟 BLL 有事件通知机制。因为表现层本来就是调用 BLL的，这很自然。 你如果不是表现层跟BLL的关系，就不要盲目抄代码。

[圣殿骑士18]

哪有那么复杂的，这就是你架构有问题，从而生生的被你创造出来的问题。改善你的架构，问题自然消失。

[煮吧姐]

之前对三层领悟没有深入,现在对项目重新架构发现之前项目开发过程中的要求不到位,编写混乱导致很多东西塞不进来,为此与同事讨论新架构模式,产生了争议,,想求得答案. 现项目是多主体项目 三个核心 暂定为 办公系统OA 网站WEB 博客NOTE 思路A: 思路B: 因对大项目架构经验欠缺,若基础就有所问题,请各位指出.谢谢 分析: A方法 ------ 清晰,但是涉及到如上面所术的问题,实体现在不在单单是数据库类,加入一些映射关系,但是之前的编写方法是在实体类中调用函数操作DAL获取对象. 看到上面朋友们的回答总结: 1.实体类 为对象为纯粹的传输载体,不可以操作DAL BLL的操作 2.如果要建立实体类的主外类关系映射需要在BLL建立 解决办法 1.使用类EF的ORM工具,但在项目中已经使用tt模板生成了 增删改查模板,只需要小巧的映射关系获取关联对象即可,该如何选择? 2.使用BLL层关联父子类关系,这样会大大加重代码量,并且有业务调用仅需要流程主表数据即可,有些业务需要流程主表信息及相关操作日志,那该如何处理 B方法 ---------- B方法,操作相对灵活,因DAL 和 实体层 合并,其中编写内容可以相互操作,但缺点是BLL UI 层需要实体层的时候直接将DAL也引入了项目 总结 陷入迷乱...

引用 8 楼 正怒月神 的回复:

两种方案 1 要么设置实体之间的关联关系。也就是主外键关联 2 要么 在业务逻辑层去实现他们的关系。

引用 6 楼 道潯常 的回复:

[quote=引用 5 楼 以专业开发人员为伍 的回复:] model 本来就应该嵌套实现。 有的人说 model 跟数据库表一样，那纯粹是误解。现在大多数关系数据库表只可能是一个二维表，表中记录字段不能嵌套其它对象。而 Model 是为了跨层传递对象用的，自然就是可以是嵌套的数据结构。所以 Model 并不对应一个个数据库表。从 Model 如何对应各个数据库表，那是 BLL 代码中去具体操作 DAL 的事情，而 BLL 对外输入输出参数使用 Model，表现层不关心数据库问题。 所以说，所谓“三层结构”中，你的远程调用 BLL 的接口需要获得什么 Model 就返回什么实体对象。一个 Model 可能对应2个数据库、2个其它 SOA 服务，8个数据库表，这都在一个 Model 中概括。这才叫做 Model。 那种以为数据库表决定 Model 的人，最后总是给用户说“你要是需求改变了，我就得重新设计软件”，结果消极怠工、只能做点小 OA 软件，做不了大软件，不敢承担需求前边万化的项目。就是因为他满脑子只有数据库表概念，而没有真正的 Model 概念。

正解，估计是被代码生成器给套住了[/quote]

[以专业开发人员为伍]

无所谓A、B方案。这其实仅仅是选择问题。只要你做好准备应对用户需求的千变万化，那么不用纠结底层（不要把大部分时间耗在底层）就可以了。

[以专业开发人员为伍]

引用 12 楼 sunwork888 的回复:

B方法,操作相对灵活,因DAL 和 实体层 合并,其中编写内容可以相互操作,但缺点是BLL UI 层需要实体层的时候直接将DAL也引入了项目

Model 跨各层来定义数据结构，例如在表现层的 Model 用来声明调用业务逻辑层的输入输出参数类型。Model 怎么可能是干”增删改查“的事情？

[以专业开发人员为伍]

真正的技术，来自于从领域业务触发进行系统分析设计，来自于丰富的交互行为、前端 ViewModel、Model，来自于BLL对整个系统的支持，甚至来自于服务器的水平扩展架构（例如可以随时卸掉一个服务器，其它服务器仍然支持整个系统不间断运营）。这是真正的技术。 有些初学者整天纠结底层的什么”增删改查“DAL，除了这些就不会把技术提高到更讲究技术的层次上去了，不会从前端出发来搞开发。满脑子只有 DAL，所以对业务问题只能纠缠在 DAL 里边来讨论。没有创意，没有“出息”。

[大鱼>]

我不知道你想问的与你上述表达的有什么必然关系，实体类可以包含另外一个实体类的对象，这和三层没什么必然关系吧

[煮吧姐]

虽然有些话不投机，但仍感谢热心回答，散分。

[煮吧姐]

引用 1 楼 道潯常 的回复:

我不知道你想问的与你上述表达的有什么必然关系，实体类可以包含另外一个实体类的对象，这和三层没什么必然关系吧

有非常大的关系,看来我的表述不明确. 我想表达的意思如图,实体类被三层引用了. 但实体类中的 流程表实体为数据中的父表,其中有一个日志子表,在程序编写中,为了便利编写,通过父实体增加属性的方法获取子实体对象. 但如此使用需要 实体类引用 DAL或BLL层调用底层方法才可以实现. 但在项目又不可重复引用,否则会提示" --------------------------- Microsoft Visual Studio --------------------------- 未能添加对“PV1.Core”的引用。将此项目作为引用添加将导致循环依赖项。 --------------------------- 确定 --------------------------- "

[煮吧姐]

寻找解决方案中发现坛子中有使用委托的解决办法,是否还有其他办法请赐教.

使用委托就可以了：
BLL中：
C# code
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
namespace BLL
{
    public class Test
    {
        public delegate void RefreshDelegate(ref string msg);
 
        public void Call(RefreshDelegate d)
        {
            string msg = string.Empty;
            for (int i = 1; i <= 10; i++)
            {
                msg = string.Format("{0}\r\n", i);
                d(ref msg);
            }
        }
    }
}

UI层：
C# code
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
namespace CSWin
{
    public partial class MainForm : Form
    {
        public MainForm()
        {
            InitializeComponent();
        }
 
        private void btn_Test_Click(object sender, EventArgs e)
        {
            BLL.Test test = new BLL.Test();
            BLL.Test.RefreshDelegate d = new BLL.Test.RefreshDelegate(Refresh);
            test.Call(d);
        }
 
        private void Refresh(ref string msg)
        {
            this.textBox1.Text += msg;
        }
    }
}

[煮吧姐]

引用 17 楼 圣殿骑士2018 的回复:

如果要建立实体类的主外类关系映射需要在BLL建立 -- 谁说关系映射必须在BLL建立的？如果你了解EF，你应该知道EF的关系映射就在Model里。

是的,昨天也是根据EF提供的思路,决定将DAL 和实体合并.因为结贴了,手动给点点赞朋友!

[圣殿骑士18]

如果要建立实体类的主外类关系映射需要在BLL建立

--
谁说关系映射必须在BLL建立的？如果你了解EF，你应该知道EF的关系映射就在Model里。

[阿璇哥哥]

感觉都很厉害啊