我需要为数据收集服务设计一个Web服务 - 并且要求Web服务不应该直接访问数据库。
Web服务将与数据收集服务进行通信,而数据收集服务又将访问数据库。那么HTTP是Web服务与数据收集服务交谈的唯一选择吗?但数据收集服务尚未开发 - 是否应该遵循Web服务能够与此服务进行通信的设计?我想确保正确实施数据收集服务,以便我可以毫不费力地完成我的部分Web服务。
答案 0 :(得分:1)
在这种情况下,将“Web服务”视为任何应用程序。毕竟,访问“数据收集服务”的代码应该适用于任何应用程序。
“数据收集服务”是对应用程序的外部依赖。因此,它应该在服务外观后面抽象。例如,一个界面。 (我将在我的例子中使用C#,因为我最熟悉它。)像这样:
public interface IDataCollectionService
{
void CollectData(SomeDataDTO data);
}
此时,使用数据收集服务的所有代码都应使用此接口类型。在开发数据收集服务之前,您可以使用模拟数据收集服务。任何具有足够功能的内存实现都可以让您继续工作。例如:
public class MockDataCollectionService : IDataCollectionService
{
public void CollectData(SomeDataDTO data)
{
// do nothing
}
}
此实现没有副作用,不会抛出错误,只是假设外部依赖项中的所有内容都按预期工作。您可以编辑/扩展此模拟以导致错误条件等。
(请注意,我使用“mock”这个词比纯粹的单元测试术语更通用。实际上,这在业界发生了很多。对于你的单元测试本身,你可以使用任何模拟库使用上面的界面创建一个实际的单元测试模拟。)
这只是一个例子,你如何构建它完全取决于你。关键是,作为外部依赖,与数据收集服务的所有交互都在一个外观之后。然后,当开发该服务时,它将不会真正重要它使用什么协议和标准。当您创建一个实现该接口的新DataCollectionService
类时,所有使用这些协议和标准的代码都将封装在该类中。项目的其余部分不会知道或关心差异。
然后,当该实现准备就绪时,您可以将其与“模拟”实现交换出来并测试系统,而无需更改应用程序中的任何其他代码。如果在以后确定协议需要再次更改,那么您需要更改(或创建新协议)的唯一事情就是实现接口的一个类。
实际上,如果您被授予访问数据库的权限,那么需要更改的只是再次构建该接口的新实现。从本质上讲,您是否可以访问数据库与使用哪些协议一样无关紧要。软件的体系结构将其抽象化,因此基础架构的架构影响尽可能小。
答案 1 :(得分:0)
您可以创建模拟数据收集服务的模拟对象,直到实际服务完成。在创建单元测试时,模拟对象可以兼作测试工具。