我们是否应该在nTier应用程序中使用WCF服务作为我们的服务层门面

因此，我们决定在我们的业务中重新构建一个应用程序，因为除了使用文档索引功能外，它没有任何明显的原因坐在Sharepoint中。我们是否应该在nTier应用程序中使用WCF服务作为我们的服务层门面

我们决定使用C＃在ASP.NET MVC3中创建我们的新应用程序。我们正在尝试确定整体架构。

我想类似如下：

核心 - 域对象（POCO的）
数据 - 实体框架（代码优先）或NHibernate的暴露库
服务 - 这层将封装任何业务逻辑并充当门面。这可以分解成更多的模块。 UI（MVC） - 控制器和视图。

这将全部使用DI容器如Autofac捆扎在一起。

我们也希望能够如此，我们需要能够嘲笑我们的服务层和数据存储库来测试我们的控制器等

所以编写单元测试 - 请问以上听起来像一个良好的整体架构模式为一个漂亮的标准业务应用程序

的想法是，数据，服务，用户界面可以参考核心，但UI将只有真正跟服务水平组件和不知道的数据等的实施细则

我的下一个问题是，在一些我们将要在我们的应用程序之外公开一些功能，例如WCF服务/ ASP.NET Web API。

在你看来，什么是最好的选择。在WCF中构建服务层，并在MVC中通过我们的控制器调用它？如果是的话，这是可测试的，或者我们需要编写一个围绕Web服务的包装？这可能会耗费时间吗？

继续写一个服务层（即Service1.CreateObject（obj对象）;）在C＃类，并创建一个Web服务作为一个独立的实体暴露只是我们需要调用我们的服务层的功能？

任何想法都会非常有帮助，因为我不知道最佳路线是什么。

来源

2012-03-06 Tom Miller

我们应该使用WCF服务作为n层应用我们的服务层门面

取决于是否有任何其他应用程序比MVC应用程序要交谈的服务。

MVC3是唯一的应用程序：你是不是gonno需要
其他应用程序也：当然。做到这一点。

在你看来，什么是最好的选择。在WCF中构建服务层，并在MVC中通过我们的控制器调用它？如果是的话，这是可测试的，或者我们需要编写一个围绕Web服务的包装？这可能会耗费时间

请勿使用具体的服务类别。使用服务接口。问题解决了。

我的下一个问题是，在某些时候，我们会想暴露我们的应用程序，即WCF服务/ ASP.NET的Web API之外的一些功能

我希望你的意思是相同的WCF服务。

继续写一个服务层（即Service1.CreateObject(object obj);）在C＃类，并创建一个Web服务作为一个独立的实体暴露只是我们需要调用我们的服务层的功能？

ehh。什么样的方法是Service1.CreateObject(object obj)？这看起来错了。

来源

2012-03-06 12:37:20 jgauffin

好吧 - 听起来好像我们将我们的服务层写成WCF服务。由于我之前没有使用过WCF，我认为它为您创建了接口？如果是这样，我们可以使用嘲笑框架轻松地嘲笑这些。 Service1.CreateObject（object obj）只是一个通用的例子，因为我不想在这篇文章中谈论我们领域模型的细节。 – 2012-03-06 12:46:32

这是相反的方式。您创建一个接口和一个实现，并且WCF为您生成一个WSDL。像EF中的CodeFirst一样。 – jgauffin 2012-03-06 12:50:15

使用WCF服务是正确的方法。（因为你需要把它作为web-api和web-api托管在http上）。

在您的mvc应用程序中，您可以使用端点url使用该服务。

时间因素取决于您的服务器（用于MVC应用程序的WebServer和用于托管WCF服务器的服务器）之间的连接性。它不应该是瓶颈。

你还可以做MVC代码的单元测试（因为服务层调用可以被模拟）（使用Moq/NMock？RhinoMock ...））

来源

2012-03-06 12:32:57 Manas

我们是否应该在nTier应用程序中使用WCF服务作为我们的服务层门面

回答

相关问题