业务库重用或公开服务

Question

我很难在两种可能的设计选择之间做出决定。我有一个网站，其中有一个相当广泛的业务层和DAL (网站，bll，和达尔都在多个独立的dal )。我需要设计一个windows服务，它可以接受我的一些业务对象，将它们写入一个文件，并在我们的网络中本地存储它们。然后将这些文件导入到第三方程序中，由第三方程序对其进行进一步处理。

我可以设计这种服务的两种方式之一：

1. 围绕业务层和DAL包装服务。这将是快速和容易的，但缺点是，每次业务层的变化，服务将不得不更新。
2. 添加一个web服务到网站，只需查询web服务，以了解我需要什么。windows服务不需要使用业务层，只要web服务不改变，我就会很好。唯一的缺点是，我可能不得不创建一些基本的业务对象来将web服务的xml解析为。

windows服务必须每10-20分钟左右轮询一次业务层/达尔或web服务。windows服务是必要的，因为网站是在网站之外托管的，因此无法访问我们的任何本地资源。我倾向于选择2，但我很困惑。

考虑到这两种选择，哪一种选择更好？还有其他可能的选择我没有考虑过吗？另外，您通常如何设计一个核心库集，这些库主要由一个网站使用，但最终可能被用于数据检索或执行某些功能？

Answer 1

我不确定将某些业务对象作为文件存储在网络上的标准是什么，但是如果您是定期地这样做，那么您大概是在试图跟踪某些类型的更改，因此还有另一种解决方案:将逻辑直接构建到业务/持久层。

如果这个辅助文件存储是业务需求，那么它应该直接嵌入到该层中，并由某种事件触发。这样，你就没有一个本质上是一个临时的后处理任务，它可能与系统的其他部分不同步，你只有一个连贯的系统。

反转设计--而不是围绕业务服务包装web服务并将其用于临时报告，而是创建一个web服务，定期封装从导出中接收到的数据，并让您的业务层在新数据准备好时向其发送消息。您可以异步发送消息，以避免捆绑业务服务，并且根据您的可靠性要求，您可以设置一个消息队列(它比听起来容易，WCF已经知道如何使用MSMQ作为传递机制，它只是一些需要更改的配置设置)。

我不能肯定地说，这比您的前两个选项更好，而不知道更多关于体系结构、数据的数量和类型、日程安排和报告要求等方面的知识，但这是您应该考虑的事情。如果您认为您的业务服务可能会相当频繁地更改，那么如果它将数据推到“仓库”类型的抽象中，而不是让挖掘过程来提取它，它可能会更好地工作。

否则，我想我会选择选项2，我不知道您以前是否使用过WCF服务，但是您应该知道，您从来不需要解析XML。一切都是通过数据契约完成的，当您为web服务生成代理时，您会得到强类型的.NET对象。如果您可以通过服务API直接传递您的域对象，那么创建web服务的工作非常少。

web服务的真正缺点是，您必须采取措施确保您的服务契约不会发生实质性变化(否则它会破坏客户端)。因此，您最终可能需要在服务端创建数据传输对象，以作为公共API使用，而不是通过域对象。但是在很多情况下，你不需要做很长时间，所以继续尝试，你会发现它是非常简单的。

Answer 2

备选案文二的一个备选案文：

向站点添加WCF服务，将所需的信息作为基本的DTO DataContracts公开。您可以在WCF服务中使用AutoMapper或类似的方法来处理将业务对象转换为DTO的无聊部分。

Answer 3

为了获得更大的灵活性，而不是在业务和DAL周围硬包装您的服务，而不是依赖网站(通过集成的web服务)，而是使用设计概念，比如：interfaces、动态加载、控制反转，这样您的服务就是一个瘦的解耦层，它与业务和DAL通信，允许动态更新业务和DAL，而无需重新编译服务。可能会将程序集放在机器的全局程序集缓存中，以便在其他各种项目、程序集和应用程序之间共享。

我知道这听起来像是为了它而抛开行话，但这就是我开始思考的方式。

编辑：

动态加载类型实际上是惊人的和容易的。这是一种快速的C#伪代码，如果不进行测试，它可能实际上是正确的。

// Get a System.Type from string representation
Type t = Type.GetType("type name");
// Create instance of type.
object o = Activator.CreateInstance(t);
// Cast it to the interface (or actual Type) you're working with.
IMyInterface strongObject = (IMyInterface)o;
// ... and continue from there with the instance.

有关如何构造类型名称的字符串表示形式的说明可在Type.AssemblyQualifiedName、Type.GetType和类似位置下的MSDN中找到。简而言之，您可以在app.config或web.config文件中看到许多程序集限定类型名称，因为它们使用相同的格式。