asp.net-mvc-3 - 我们是否应该在 nTier 应用程序中使用 WCF 服务作为我们的服务层外观

Question

因此，我们决定在我们的业务中重建一个应用程序，因为它一直在 Sharepoint 中，除了利用其文档索引功能之外没有明显的原因。

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

我在想类似以下的事情:

核心 - 域对象(poco 的)

数据 - Entity Framework (代码优先)或 nHibernate 公开为存储库

服务 - 该层将封装任何业务逻辑并充当外观。这可以分解为更多的模块。

UI (MVC) - Controller 和 View 。

所有这些都将使用 DI 容器(例如 Autofac)捆绑在一起。

我们还希望能够编写单元测试，因此我们需要能够模拟我们的服务层和数据存储库以测试我们的 Controller 等。

那么——对于一个非常标准的业务应用程序来说，以上听起来像是一个很好的整体架构模式吗？

这个想法是数据，服务，用户界面可以引用核心，但用户界面只会真正与服务级别组件对话，而不知道数据等的实现细节。

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

在您看来，什么是最好的选择。在 WCF 中构建服务层并从 MVC 中的 Controller 调用它？如果是这样，这将是可测试的，还是我们需要围绕 Web 服务编写一个包装器？这会很耗时吗？

或者

继续在 C# 类中编写服务层(即 Service1.CreateObject(object obj);)并创建一个 Web 服务作为单独的实体，仅公开我们需要调用服务层的功能？

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

Answer 1

Should we use a WCF service as our service layer facade in nTier application

取决于除 MVC 应用程序之外的任何其他应用程序是否要与服务通信。

MVC3 是唯一的应用程序 : 你不需要它

其他应用程序也是 : 当然。去做吧。

What, in your view, would be the best option. Build the service layer in WCF and call this from our Controllers in MVC? If so would this be testable or would we need to write a wrapper around the web service? Could this be time consuming

不要使用具体的服务类。使用服务接口(interface)。问题解决了。

My next question is that at some point we're going to want to expose some functionality outside our application i.e. WCF Services/ASP.NET Web API

我希望您指的是相同的 WCF 服务。

Continue writing a service layer (i.e. Service1.CreateObject(object obj);) in C# classes and create a web service as a separate entity exposing just the functionality we need that calls our service layer?

嗯。 Service1.CreateObject(object obj)是什么方法| ?这看起来是错误的。