所以我们决定在我们的业务中重建一个应用程序，因为除了使用它的文档索引功能之外，它没有任何明显的理由而在Sharepoint中。
我们决定使用C＃在ASP.NET MVC3中创建我们的新应用程序。我们正试图决定整体架构。
我在考虑以下内容：
这将使用诸如Autofac之类的DI容器捆绑在一起。
我们还希望能够编写单元测试，因此我们需要能够模拟我们的服务层和数据存储库来测试我们的控制器等。
那么 - 对于一个非常标准的商业应用程序，上述听起来像是一个很好的整体架构模式吗？
这个想法是数据，服务，ui可以引用Core但UI只会真正与服务级别组件通信，而不知道数据的实现细节等。
我的下一个问题是，在某些时候，我们希望在我们的应用程序之外公开一些功能，即WCF服务/ ASP.NET Web API。
在您看来，什么是最佳选择。在WCF中构建服务层并从MVC中的控制器调用它？如果是这样，这是可测试的还是我们需要围绕Web服务编写一个包装器？这可能是耗时的吗？
OR
继续在C＃类中编写服务层（即Service1.CreateObject（object obj）;）并创建一个Web服务作为一个单独的实体，只暴露我们调用服务层所需的功能？
任何想法都会非常有用，因为我不知道最佳路线是什么。
答案 0 :(得分：2)
我们是否应该在nTier应用程序中使用WCF服务作为我们的服务层外观
取决于MVC应用程序之外的任何其他应用程序是否将与服务进行通信。
在您看来，什么是最佳选择。在WCF中构建服务层并从MVC中的控制器调用它？如果是这样，这是可测试的还是我们需要围绕Web服务编写一个包装器？这可能是耗时的
不要使用具体的服务类。使用服务接口。问题解决了。
我的下一个问题是，在某些时候我们想要在我们的应用程序之外公开一些功能，即WCF服务/ ASP.NET Web API
我希望您的意思是相同的WCF服务。
继续在C＃类中编写服务层（即
Service1.CreateObject(object obj);）并创建一个Web服务作为一个单独的实体，只暴露我们调用服务层所需的功能？
EHH。 Service1.CreateObject(object obj)是一种什么样的方法？这看起来错了。
答案 1 :(得分：1)
使用WCF服务是正确的方法。 （因为你需要托管这个web-api和web-api是通过http）。
在您的mvc应用程序中，您可以通过端点URL使用该服务。
时间因素取决于服务器之间的连接（用于MVC app的WebServer和用于托管WCF服务的服务器）。最后它不应该是瓶颈。
你仍然可以对MVC代码进行单元测试（因为可以模拟服务层调用。（使用Moq / NMock？RhinoMock ......）