blocks|key|191113|text|对于我的业务规则，我通常有另一个层(根据应用程序的大小和复杂性，可以是不同的项目/程序集)。您可以将此业务服务称为，或者其他与您的案例相关的名称。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|191114|因此，MVC控制器和应用编程接口控制器都使用这一层；这使应用程序保持干爽。|191115|我个人倾向于只在我的业务层中保留复杂的操作，这意味着如果我需要从我的持久层读取一些东西来显示在我的视图中，我会直接在MVC控制器上进行。这是个人喜好的问题，但我更喜欢CQRS的方式。|191116|因此，MVC控制器将实例化这些业务服务(或者，如果使用IoC，它们将被注入到控制器中)。对于读取操作，您可以选择直接转到您的持久层或使用其他读取策略。|191117|同样的事情也会发生在你的API控制器上，它们将使用这个“公共”服务层。|191118|您不需要在MVC控制器上实例化API控制器。如果您正在开发SPA或类似的应用程序，则可以通过AJAX使用您的Web+Api控制器。|191119|没有一种单一的方法来构建你的应用程序，只是有不同的方法，每一种方法都或多或少地伴随着痛苦。|191120|如果您正在考虑在您的应用程序中引入测试(您应该：)；那么您应该以一种易于测试其每个部分的方式来构建它。|191121|就我的两分钱。|191122|entityMap^0|4|4|1F|6|0|3|6|A|9|0|2B|4|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@$9|Y|A|Z|B|C]|$9|10|A|11|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|12|8|@$9|13|A|14|B|C]|$9|15|A|16|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|17|8|@$9|18|A|19|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|1A|8|@]|D|@]|E|$]]|$1|L|3|M|5|6|7|1B|8|@]|D|@]|E|$]]|$1|N|3|O|5|6|7|1C|8|@]|D|@]|E|$]]|$1|P|3|Q|5|6|7|1D|8|@]|D|@]|E|$]]|$1|R|3|S|5|6|7|1E|8|@]|D|@]|E|$]]|$1|T|3|U|5|6|7|1F|8|@]|D|@]|E|$]]|$1|V|3|-4|5|6|7|1G|8|@]|D|@]|E|$]]]|W|$]]

I usually have another layer (which can be a different project/assembly depending on the size and complexity of your application) for my business rules. You can call this business services, or whatever works on your case.

So both MVC controllers and API controllers use this layer; which keeps the application dry.

I personally prefer to only keep complex operations in my business layers, which means if I need to read something from my persistence layer to display in my views, I do it directly on the MVC controller. This is a matter of personal preference but I prefer to go the CQRS way.

So you MVC controllers are going to instantiate these business services (or they will be injected into your controllers if you are using IoC). For read operations you can choose to go straight to your persistance layer or use another read strategy.

The same will happen to your API controllers, they will use this "common" layer of services.

You don't need to instantiate your API Controllers on your MVC Controllers.
Consuming your Web Api controllers via AJAX is ok if you are developing a SPA or similar.

There is no a single way to structure your application, there are just different ways and every one has more or less pain attached.

If you are considering introducing tests in your applications (and you should :)); then you should structure it in a way it is easy to test each part of it.

Just my 2 cents.

blocks|key|2813217|text|Web+API的全部要点是成为一个无状态的RESTful服务。如果你做得对，就永远不会有这样的例子。我知道这个问题很老了，你个人可能已经学过了，但答案对你来说并不多，因为它是对一个常见问题的答案。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2813218|请注意，当谈到Web时，人们通常谈论的是ApiControllers，而不是基本的MVC“控制器”，这些控制器采用路由并将它们转换为视图。|2813219|因此，在您的项目中，您可能有一些“控制器”，它们执行一些基本的视图逻辑，但没有业务逻辑。不要将其与服务层混淆，服务层是业务逻辑和持久性访问的包装器。|2813220|我和许多人都认为ApiControllers不应该和你的MVC应用程序混在一起。请记住，MVC与Web+API不能很好地混合。正如Filip+W所说：|2813221|2813222|+Web+API和MVC使用的许多概念，尽管乍一看很相似，但实际上并不兼容。例如，Web属性是System.Web.Http.Filters.Filter，而MVC属性是System.Web.Mvc.Filter+-并且它们不能互换。|blockquote|2813223|2813224|2813225|最灵活的答案|offset|length|style|BOLD|2813226|因此，您要做的是创建一个名为api.YourWebsite.com的子域，并在其中构建一个新的Web+API+ApiController项目。该Web+API项目只需通过ApiControllers和依赖注入实例化和公开业务逻辑即可。|2813227|备用1|2813228|面向服务的体系结构完全是关于可重用性的。如果你想让你的应用程序保持干爽，你绝对应该选择SOA。然而，每种情况都是不同的。如果您永远不会在任何其他应用程序(桌面、安卓、平板电脑、ewPhones等)中使用本网站中的相同业务逻辑，那么您有另一种方法。|2813229|将您的业务逻辑层创建为另一个项目，并直接从您的web应用程序访问它。当你的Javascript+(Angular/Razor?)控制器发出一个调用，它们可以调用你的ViewModels和/或代码隐藏或类似的东西，这可以实例化业务逻辑并直接访问它。如果所有东西都在那里并且不会被重用，就不需要服务了。|2813230|Alternative+2|2813231|继续并将您的Web+API+ApiControllers放入同一个项目中。但是，请确保将它们从MVC“控制器”中分离到不同的文件夹中。尽管如此，当您的Javascript控制器发出调用时，它们会将调用路由到您的网站以实现无状态返回。不要将无状态ApiControllers与您的ViewModels和其他MVC代码混在一起。|2813232|这样做的缺点是缺乏SOC。现在，您混合了服务层和UI层，并且您的UI层被强制访问您的业务逻辑层(DLL)。如果Alternative+1做到了，那有什么错呢？|2813233|好吧，错误的是，Alternative+1是一个没有增长空间的小应用程序。其他任何东西(原始计划，或这里的备选方案2)都应该有UI，这些UI根本不知道业务逻辑(或持久性)是否存在。他们应该在不知道后端世界的情况下做他们的坏事。|2813234|entityMap^0|0|0|0|0|0|0|0|0|0|6|0|0|0|3|0|0|0|0|D|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1C|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1D|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1E|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|I|3|J|5|K|7|1G|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1J|8|@$P|1K|Q|1L|R|S]]|9|@]|A|$]]|$1|T|3|U|5|6|7|1M|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1N|8|@$P|1O|Q|1P|R|S]]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|1R|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|1S|8|@$P|1T|Q|1U|R|S]]|9|@]|A|$]]|$1|13|3|14|5|6|7|1V|8|@]|9|@]|A|$]]|$1|15|3|16|5|6|7|1W|8|@]|9|@]|A|$]]|$1|17|3|18|5|6|7|1X|8|@]|9|@]|A|$]]|$1|19|3|-4|5|6|7|1Y|8|@]|9|@]|A|$]]]|1A|$]]

The whole point of Web API is to be a stateless RESTful service. There would never be an instance of it if you're doing it right. I realize this question is old and you may personally have learned this, but the answer isn't as much for you as it is an answer to a frequently-asked question.

Note that when speaking of Web API, more often than not, people are talking about ApiControllers and not basic MVC "Controllers" that take routes and turn them into Views.

So in your project, you may have some "Controllers" which do some basic view logic, but no business logic. Don't confuse that with your Service Layer which is a wrapper for your Business Logic and Persistence access.

I, and many, am of the opinion that ApiControllers shouldn't be mixed with your MVC application. Keep in mind that MVC does not mix well with Web API. As Filip W says:

<blockquote>
 Many of the concepts used by Web API and MVC, even though similar at
 first glance, are actually not compatible. For example, Web API
 attributes are System.Web.Http.Filters.Filter and MVC attributes are
 System.Web.Mvc.Filter - and they are not interchangeable.
</blockquote>

Most flexible answer

So what you do is create a subdomain named api.YourWebsite.com, and build a new Web API ApiController project there. That Web API Project should do NOTHING more than instantiate and expose Business Logic via ApiControllers and Dependency Injection.

Alternative 1

Service-Oriented Architecture is all about reusability. If you want to keep your applications DRY, you should definitely fall into SOA. Though, every situation is different. If you will never ever use the same business logic in this website in any other application (desktop, android, tablet, ewPhones, etc), then you have an alternative method.

Create your Busines Logic Layer as a different Project, and access it directly from your web app. When your Javascript (Angular/Razor?) Controllers make a call, they can call into your ViewModels and/or Codebehind or something similar, which can instantiate Business Logic and directly access it. No need for services if everything is right there and won't be reused.

Alternative 2

Go ahead and put your Web API ApiControllers in the same project. But, be sure you separate them into different folders from your MVC "Controllers." Still, when your Javascript Controllers make a call, they will be making Routing calls to your website for stateless returns. Do not mix the stateless ApiControllers with your ViewModels and other MVC code.

The downside to this is a lack of SOC. Now you have Service-Layer and UI-Layer mixed, and your UI-Layer is forced to access your Business Logic Layer (DLL). What's wrong with that if Alternative 1 did it?

Well, what's wrong is that Alternative 1 was a small application with no room for growth. Anything else (The original plan, or Alternative 2 here) should have UI's that have no clue whatsoever that Business Logic (or Persistence) even exist. They should go about their doodies unawares of the backend world.

I am about to create a simple web app and I am wondering if I should use ASP.NET MVC 4 new feature <code>Web API</code>.

What's the best way to do this ?

I've done some researches and I found out there are two option :

<code>Option 1</code>

Make the Web Api my service layer and call it from the controller to read/write data, and render the view using view models and razor.

<code>Option 2</code>

Make the Web Api my service layer and call it directly from the view using Javascript.

I am not a big fan of <code>Option 2</code> since I feel like I am neglecting the controller which will be used only for redirection between pages. Besides I prefer using razor rather than Javascript.

And If I choose <code>Option 1</code> will I have to make an instance of one Web API in the controller? because this feels like I am doing something wrong. 

What's the best option ? Is there any other options I haven't considered ?

And if you can give some references or books which can help me, I would appreciate it. 

Thanks.

How to combine Web Api and MVC best in a single web app

路由

我即将创建一个简单的web应用程序，我想知道我是否应该使用ASP.NET MVC4的新功能Web API。做这件事最好的方法是什么？我做了一些研究，我发现有两个选择：Option 1使Web Api成为我的服务层，并从控制器调用它来读/写数据，并使用视图模型和razor呈现视图。Option 2使Web Api成为我的...

问如何在单个Web应用程序中最好地结合web Api和MVC
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何在单个Web应用程序中最好地结合web Api和MVCEN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何在单个Web应用程序中最好地结合web Api和MVC
EN