为业务层和表示层之间的通信服务的对象

时间:2009-06-02 19:47:44

标签: communication layer

这是关于设计的一般问题。在业务层和表示层之间进行通信的最佳方式是什么?我们目前有一个对象可以传递到我们的业务层,服务从对象读取信息并将结果设置到对象中。当服务完成后,我们将有一个填充了业务层结果的对象,然后UI可以根据对象的结果显示。

这是最好的方法吗?还有什么其他方法?

3 个答案:

答案 0 :(得分:1)

领域驱动设计书籍(快速版本可自由使用here)可以让您深入了解这一点。

简而言之,他们提出了以下方法:模型对象从模型层横向到视图层无缝(如果您在clinet / server上使用静态类型语言或不同语言,这可能会很棘手,但它在动态上很简单那些)。此外,服务仅应用于执行不属于模型对象本身的操作(或者当您有一个涉及大量模型对象的操作时)。

此外,业务逻辑应该放入模型层(实体,服务,值对象),以防止着名的anemic domain model反模式。

这是另一种方法。如果它适合你,那很大程度上取决于团队,代码编写了多少,你有多少测试覆盖率,项目有多长,你的团队是否敏捷,等等。领域驱动设计可以进一步快速地讨论它,如果你至少首先浏览它,那么任何决定的风险都会大大降低(如果你选择深入研究,那么从埃里克埃文斯获取原版书会有所帮助)。

答案 1 :(得分:0)

我们使用侦听器模式,并在业务层中将事件发送到表示层。

答案 2 :(得分:0)

这取决于您的架构。

有些人在同一个exe或dll中构建他们的代码并遵循标准的n层架构。

其他人可能将其拆分出来,以便他们的服务都是Web服务而不仅仅是标准类。这样做的好处是可以在物理基础架构中的一个位置安装可重用的业务逻辑。所以单个更改适用于所有应用程序。

软件即服务和云计算正在成为事物发展的平台。 Amazons Elastic cloud,Microsofts Azure和其他云提供商都提供了许多可能影响您的架构决策的服务。

我即将使用的是

Silverlight UI

WCF服务 - 这里的业务逻辑

NHibernate数据访问

Sql Server数据库

我们只允许应用程序的各层通过接口进行通信,这样一旦它变得更加成熟,我们就可以升级到Azure云服务。