这是一个关于设计的普遍问题。在您的业务层和表示层之间进行通信的最佳方式是什么?我们目前有一个对象传递到我们的业务层,服务从对象读取信息并将结果设置到对象中。服务完成后,我们将使用业务层的结果填充一个对象,然后 UI 可以根据对象的结果显示。
这是最好的方法吗?还有什么其他方法?
这是一个关于设计的普遍问题。在您的业务层和表示层之间进行通信的最佳方式是什么?我们目前有一个对象传递到我们的业务层,服务从对象读取信息并将结果设置到对象中。服务完成后,我们将使用业务层的结果填充一个对象,然后 UI 可以根据对象的结果显示。
这是最好的方法吗?还有什么其他方法?
领域驱动设计书籍(快速版本可在此处免费获得)可以让您深入了解这一点。
简而言之,他们建议采用以下方法:模型对象从模型层无缝横向到视图层(如果您在 clinet/server 上使用静态类型语言或不同语言,这可能会很棘手,但在动态语言上却很简单)。此外,服务只能用于执行不属于模型对象本身的操作(或者当您的操作涉及大量模型对象时)。
此外,应将业务逻辑放入模型层(实体、服务、值对象),以防止著名的贫血领域模型反模式。
这是另一种方法。如果它适合你,它在很大程度上取决于团队,编写了多少代码,你有多少测试覆盖率,项目有多长,你的团队是否敏捷,等等。领域驱动设计很快就进一步讨论了它,如果你至少先略读它,任何决定的风险都会大大降低(如果你选择进一步深入研究,从 Eric Evans 那里获得原著会有所帮助)。
我们使用侦听器模式,并让业务层中的事件将信息发送到表示层。
这取决于您的架构。
有些人在同一个 exe 或 dll 中构建他们的代码,并遵循标准的 n 层架构。
其他人可能会将其拆分,以便他们的服务都是 Web 服务,而不仅仅是标准类。这样做的好处是可重用的业务逻辑安装在您的物理基础设施的一个地方。因此,单个更改适用于所有应用程序。
软件即服务和云计算正在成为事物发展的平台。Amazon 的 Elastic Cloud、Microsoft 的 Azure 和其他云提供商都提供了大量服务,这些服务可能会影响您的架构决策。
我将要使用的一个是
Silverlight 用户界面
WCF 服务 - 这里的业务逻辑
NHibernate 数据访问
Sql 服务器数据库
我们将只允许应用程序的各个层通过接口进行通信,以便一旦 Azure 云服务变得更加成熟,我们就可以升级到它。