blocks|key|699865|text|通常这些术语只是在其特定的上下文中使用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|699866|API‘Facade’常见用法上下文:用于应用程序复杂部分的简单(如第三方|699867|上下文:解锁和显示系统中的业务实体。(面向服务架构、DAO、安全等)+|unordered-list-item|699868|699869|您可以将模式视为一种不断发展的语言。这似乎从来都不是完美的结局，每个模式都有它自己的历史和背景。有时类可以同时被视为服务和外观，有时则不是。|699870|例如:由于上下文错误，使用术语“服务”调用第三方API可能会被认为是误用。|699871|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|P|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

Usually these terms are just used in their specific contexts. 

<ul>
<li>'Facade' common usage context: simple API for complex parts of the application (like third-party libs)</li>
<li>'Services' context: unlock and surface the business entities in the system. (SOA, DAO, Security, etc) </li>
</ul>

You can view patterns as a language that evolves. It never seemed to be perfect end each pattern has it's own history and context. Sometimes classes could be viewed as Services and Facades at the same time, sometimes not. 

For example: calling third party API by term 'Service' could be considered as misuse, because of the wrong context.

blocks|key|1871850|text|服务接口通常表示业务关注点:执行一些操作和/或获取一些信息。对于服务提供者来说，将他们的服务实现为内部后端服务的外观并不是不合理的-您永远不会看到这一点。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1871851|您的外观可能会包装一些通用接口，其中可能包括服务接口。|1871852|例如，您可能有一个银行帐户的服务接口(操作:银行转账)，以及一个本地会计记录的本地API+(I+transfer+money)。您可以引入一个外观，其中包含一个"move+money“操作，该操作使用银行的服务接口并管理本地支票簿。|1871853|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

A service interface typically represents business concerns: perform some operation(s) and/or get some information. It wouldn't be unreasonable for the service provider to implement their service as a facade over internal back-end services - you'd never see this.

Your facade might wrap some general interfaces, which might include service interface(s).

For example, you might have service interface for a bank account (operation: Bank transfers money), and a local API to your local accounting records (I transfer money). You might introduce a facade over with a "move money" operation that uses the bank's service interface and manages your local checkbook as well.

blocks|key|1871920|text|服务是一种向外部系统编写接口的方式，例如LDAP身份存储、支付网关或应用程序管理接口。这是一种概念性的方法，将外部系统视为有用服务的提供者，可能具有内部行为，而不是要操作的被动块。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1871921|外观是一种包装任何东西(包括服务)的方式，以便将其很好地呈现给另一个组件。外观通常在以下情况下使用：|1871922|1871923|库或组件很复杂，您的应用程序只需要它的一个子集。您的外观将简化的API呈现给使用了几个库或组件的application|unordered-list-item|1871924|You，并且需要统一它们，向您正在使用的application|1871925|The库呈现统一的API需要一个复杂的设置或一组依赖项，并且Facade将所有这些都包装在您的应用程序的上下文中。|1871926|1871927|真正令人困惑的是，您可以(并且经常这样做)在一个或多个服务上创建外观。服务是组件实际访问资源的方式，外观是简化组件(如配置选项、连接等)的部分。|1871928|如果您编写自己的DAO，您可能会根据需要创建您的服务，因此编写facade表明您做错了。如果DAO是由第三方构建的，并且比您的需求更复杂，那么您可以对服务进行外观处理。|1871929|1871930|现在，服务是一种对多个DAO执行调用以获得复杂数据结构的方法(我对此不太确定，但这是我到目前为止所理解的)。|blockquote|1871931|1871932|1871933|我想说DAO是一种完全独立的设计模式--+see+wikipedia。|offset|length|1871934|如果我们将DAO与服务进行比较，我们会得到：|1871935|对properties|1871936|Service:的细粒度访问粗粒度对services|1871937|
的访问：|1871938|级别的|1871939|DAO|1871940|1871941|1871942|​|1871943|实现所在的|1871944|：|1871945|DAO:主要在客户端，但在database|1871946|Service:中存储数据(无行为)主要在server|1871947|1871948|上|1871949|1871950|1871951|如何调用JVM+DAO接口:客户端直接绑定到相同名称空间和|1871952|1871953|服务中的对象:客户端只是网络、跨vm或跨名称空间服务的存根|1871954|1871955|1871956|1871957|1871958|+...facade可以完美地访问多个DAO，以便通过提供一个简单的接口来执行复杂的操作，并且服务看起来类似于某些东西。|1871959|1871960|1871961|facade可以包装DAO层，但我并不认为这是一种有用的方式。您很可能需要一个API来访问对象的各个属性、遍历对象图等，而这正是DAO所提供的。|1871962|1871963|事务也是如此，我知道服务是开始事务的地方……|1871964|1871965|1871966|当然可以，因为事务是由数据库和另一个组件或系统提供的服务|1871967|1871968|+...但我同样觉得它们也可以放在facade上，毕竟一个facade也可以调用多个DAO。|1871969|1871970|1871971|在许多方面，事务管理器服务是复杂得多的后端实现的门面，协调web、应用程序、数据库和其他事务感知组件上的事务。然而，这已经被事务服务实现抽象出来了。就我们用户而言，只有公共接口。|1871972|事实上，这是这些设计模式的概念点-为用户提供适量的API，抽象出组件接口铁墙后面实现的复杂性。|1871973|1871974|，因此哪个堆栈更有意义|1871975|1871976|控制器-门面-道控制器-服务-道|1871977|或者也许|1871978|controller-facadade-dao，有时是controller-facade-service-dao+?？|1871979|1871980|1871981|+DAO是对数据库的一种服务，但实际上DAO本身就是一种设计模式。|ordered-list-item|1871982|如果您编写自己的DAO，则永远不需要facade。|1871983|1871984|因此，正确的答案是：|1871985|1871986|控制器-+dao|1871987|1871988|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Data_access_object^0|0|0|0|0|0|0|0|0|0|0|0|0|0|L|D|0|0|0|0|0|0|1|1|0|0|0|0|1|1|1|0|0|0|0|1|1|1|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|3K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|3L|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|3M|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|3N|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|3O|8|@]|9|@]|A|$]]|$1|J|3|K|5|G|7|3P|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|3Q|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|3R|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|3S|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|3T|8|@]|9|@]|A|$]]|$1|R|3|S|5|T|7|3U|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|3V|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|3W|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|3X|8|@]|9|@$Y|3Y|Z|3Z|1|40]]|A|$]]|$1|10|3|11|5|6|7|41|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|42|8|@]|9|@]|A|$]]|$1|14|3|15|5|G|7|43|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|44|8|@]|9|@]|A|$]]|$1|18|3|19|5|G|7|45|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|G|7|46|8|@]|9|@]|A|$]]|$1|1C|3|-4|5|6|7|47|8|@]|9|@]|A|$]]|$1|1D|3|-4|5|6|7|48|8|@]|9|@]|A|$]]|$1|1E|3|1F|5|6|7|49|8|@]|9|@]|A|$]]|$1|1G|3|1H|5|6|7|4A|8|@]|9|@]|A|$]]|$1|1I|3|1J|5|G|7|4B|8|@]|9|@]|A|$]]|$1|1K|3|1L|5|G|7|4C|8|@]|9|@]|A|$]]|$1|1M|3|1N|5|G|7|4D|8|@]|9|@]|A|$]]|$1|1O|3|-4|5|6|7|4E|8|@]|9|@]|A|$]]|$1|1P|3|1Q|5|6|7|4F|8|@]|9|@]|A|$]]|$1|1R|3|1F|5|6|7|4G|8|@]|9|@]|A|$]]|$1|1S|3|-4|5|6|7|4H|8|@]|9|@]|A|$]]|$1|1T|3|1U|5|G|7|4I|8|@]|9|@]|A|$]]|$1|1V|3|-4|5|G|7|4J|8|@]|9|@]|A|$]]|$1|1W|3|1X|5|G|7|4K|8|@]|9|@]|A|$]]|$1|1Y|3|-4|5|6|7|4L|8|@]|9|@]|A|$]]|$1|1Z|3|-4|5|6|7|4M|8|@]|9|@]|A|$]]|$1|20|3|1F|5|6|7|4N|8|@]|9|@]|A|$]]|$1|21|3|-4|5|6|7|4O|8|@]|9|@]|A|$]]|$1|22|3|23|5|T|7|4P|8|@]|9|@]|A|$]]|$1|24|3|-4|5|6|7|4Q|8|@]|9|@]|A|$]]|$1|25|3|-4|5|6|7|4R|8|@]|9|@]|A|$]]|$1|26|3|27|5|6|7|4S|8|@]|9|@]|A|$]]|$1|28|3|-4|5|6|7|4T|8|@]|9|@]|A|$]]|$1|29|3|2A|5|T|7|4U|8|@]|9|@]|A|$]]|$1|2B|3|-4|5|6|7|4V|8|@]|9|@]|A|$]]|$1|2C|3|-4|5|6|7|4W|8|@]|9|@]|A|$]]|$1|2D|3|2E|5|6|7|4X|8|@]|9|@]|A|$]]|$1|2F|3|-4|5|6|7|4Y|8|@]|9|@]|A|$]]|$1|2G|3|2H|5|T|7|4Z|8|@]|9|@]|A|$]]|$1|2I|3|-4|5|6|7|50|8|@]|9|@]|A|$]]|$1|2J|3|-4|5|6|7|51|8|@]|9|@]|A|$]]|$1|2K|3|2L|5|6|7|52|8|@]|9|@]|A|$]]|$1|2M|3|2N|5|6|7|53|8|@]|9|@]|A|$]]|$1|2O|3|-4|5|6|7|54|8|@]|9|@]|A|$]]|$1|2P|3|2Q|5|T|7|55|8|@]|9|@]|A|$]]|$1|2R|3|-4|5|6|7|56|8|@]|9|@]|A|$]]|$1|2S|3|2T|5|6|7|57|8|@]|9|@]|A|$]]|$1|2U|3|2V|5|6|7|58|8|@]|9|@]|A|$]]|$1|2W|3|2X|5|6|7|59|8|@]|9|@]|A|$]]|$1|2Y|3|-4|5|6|7|5A|8|@]|9|@]|A|$]]|$1|2Z|3|-4|5|6|7|5B|8|@]|9|@]|A|$]]|$1|30|3|31|5|32|7|5C|8|@]|9|@]|A|$]]|$1|33|3|34|5|32|7|5D|8|@]|9|@]|A|$]]|$1|35|3|-4|5|6|7|5E|8|@]|9|@]|A|$]]|$1|36|3|37|5|6|7|5F|8|@]|9|@]|A|$]]|$1|38|3|-4|5|6|7|5G|8|@]|9|@]|A|$]]|$1|39|3|3A|5|G|7|5H|8|@]|9|@]|A|$]]|$1|3B|3|-4|5|6|7|5I|8|@]|9|@]|A|$]]|$1|3C|3|-4|5|6|7|5J|8|@]|9|@]|A|$]]]|3D|$3E|$5|3F|3G|3H|A|$3I|3J]]]]

A service is a way of writing an interface to an external system, such as a LDAP identity store, a payment gateway or an application management interface. It's a conceptual way of looking at the external system as a provider of useful services perhaps with internal behaviours rather than a passive lump to be operated upon.

A facade is a way of wrapping up anything (including a service) to present it nicely to another component. Facades are often used when:

<ul>
<li>A library or component is complex and your application needs only a subset of it. Your Facade presents the simplified API to the application</li>
<li>You are using several libraries or components and need to unify them, presenting a consolidated API to the application</li>
<li>The library you are using has a complex setup or set of dependencies, and the facade wraps all that up in the context of your application.</li>
</ul>

The bit that is really confusing is that you can (and often do) create a facade over one or more services. The service is the way that the component actually accesses the resource, and the facade is the bit which simplifies the component (such as configuration of options, connecting, etc).

If you write your own DAO, you probably will create your service just how you need, so writing a facade is an indication you did it wrong. If the DAO is built by a third party, and is more complex than your needs, then you can facade the service.

<blockquote>
 Now, a service is a way to perform calls to several DAOs in order to get complex data structures (I am not too sure of this, but is is what I understand so far).
</blockquote>

I would say that the DAO is a design pattern all its own - <a href="http://en.wikipedia.org/wiki/Data_access_object">see wikipedia</a>. 

If we contrast a DAO with a service, we have:

<ul>
<li>Level of API:
<ul>
<li>DAO: Fine-grained access to properties</li>
<li>Service: Coarse-grained access to services</li>
</ul></li>
<li>Where implementation lies:
<ul>
<li>DAO: Mainly on the client, but storing data (without behavior) in the database</li>
<li>Service: Mainly on the server</li>
</ul></li>
<li>How the interface is invoked
<ul>
<li>DAO: The client directly binds to the object in the same namespace and JVM</li>
<li>Service: The client is simply a stub for a network, cross-vm or cross-namespace operation</li>
</ul></li>
</ul>

<blockquote>
 ... the facade can perfectly access several DAOs in order to perform a complex operation by providing a simple interface, and a service seems to to something similar.
</blockquote>

A facade could wrap up the DAO layer, but I don't really see this happening in a useful way. Most likely you need an API to access the individual properties of the objects, traverse the object graph and similar, and that is precisely what the DAO provides. 

<blockquote>
 Same happens with transactions, I understand that a service is the place to start transactions ...
</blockquote>

Absolutely, because the transaction is a service provided by the database and on another component or system

<blockquote>
 ... but I equally feel that they could also be placed on facades, after all, a facade may call several DAOs too.
</blockquote>

And in many ways the transaction manager service is a facade onto a much more complex backend implementation, co-ordinating the transaction on the web, application, database and other transaction-aware components. However this is already abstracted away by the transaction service implementation. As far as we, the user, are concerned, there is only the public interface. 

This is, in fact, the conceptual point of these design patterns - to provide just the right amount of API to the user, abstracting the complexities of the implementation behind the iron wall of the component interface.

<blockquote>
 So which stack would make more sense
 
 controller-facade-dao controller-service-dao
 
 or maybe
 
 controller-facadade-dao AND sometimes controller-facade-service-dao ??
</blockquote>

<ol>
<li>The DAO is a kind of service to the database, but really the DAO is a design pattern itself. </li>
<li>If you write your own DAO, you should never need a facade. </li>
</ol>

Therefore the correct answer is:

<ul>
<li>controller - dao</li>
</ul>

blocks|key|699358|text|重要的是“上下文”。Facade和Service并不冲突。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|699359|首先，我从来没有听说过MVC上下文中的“服务”和“外观”。|699360|当人们谈论服务时，更多的是指系统或组件向外部世界提供有业务意义的操作。有时，您可能会看到与“工作单元”(以及事务)相关的“服务”。|699361|服务也用在应用程序的一些分层方法的上下文中:我们在DAO之上有服务，服务将通过DAO访问数据，业务逻辑放在服务层，诸如此类。|699362|Facade通常在设计模式的上下文中使用，重点是“隐藏复杂的操作并将其公开为简单的操作”。|699363|外观可能是服务，也可能不是服务(外观中的操作可能不代表工作单元，但它仍然是有效的外观)，类似地，服务可能是外观，也可能不是外观(服务可能不会隐藏任何复杂的操作，但它仍然是服务)。|699364|再说一次，这一切都与“上下文”有关。|699365|例如，当你谈论应用程序的分层时，说"XXX是访问DAO的门面“是不合理的。同样，如果你在谈论“设计方法”，更合理的说法是"XXX是多个后端的外观“，而不是在这里称之为”服务“(尽管XXX实际上是一个服务)。|699366|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|V|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|W|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|X|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|Y|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|Q|$]]

It is the "context" that's matters. Facade and Service are not conflicting.

First I have never heard of "Service" and "Facade" in the context of MVC. 

When people talk about Service, it is more about a system or component providing business-meaningful actions to outside world. You may sometimes see "Service" related to "Unit-of-work" (and hence, transaction).

Service is also used in the context of some layering approach of application: we have Service on top of DAO, for which Service will access data through DAO and business logic is put in Service layer, something like that.

Facade is usually used in the context of design pattern, and the focus is about "hiding complicated operations and expose it as a simple operation". 

Facade may be or may not be a Service (a operation in Facade may not represent a Unit of work, but it is still a valid facade), similarly, a Service may or may not be a Facade (a Service may not hide any complicated operations but it is still a Service).

Again, it is all about the "context" that matters.

For example, when you are talking about layering of application, it is simply irrational to say "XXX is a facade to access DAO". Similarly, if you are talking about "design approach", it is more reasonable to say "XXX is a facade to multiple back-end" instead calling it a "Service" here (Although XXX is actually a Service).

blocks|key|5706179|text|是的，Facade和Service并不是完全无关的。有时，我们将服务层实现为外观，这样客户端就不会为服务的许多细节而烦恼。服务的调用/接口越简单，客户端代码就越简单。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5706180|马丁·福勒说。|5706181|从对接客户端层的角度来看，|5706182|服务层定义了应用程序的边界Cockburn+PloP及其可用操作集。它封装了应用程序的业务逻辑，控制事务并在其操作的实现中协调响应|blockquote|5706183|5706184|5706185|因此，服务层有时被用作外观。|5706186|Ref|offset|length|5706187|entityMap|0|LINK|mutability|MUTABLE|url|http://www.manning-sandbox.com/thread.jspa?messageID=92006^0|0|0|0|0|0|0|0|0|3|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|10|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|11|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|14|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|15|8|@]|9|@$O|16|P|17|1|18]]|A|$]]|$1|Q|3|-4|5|6|7|19|8|@]|9|@]|A|$]]]|R|$S|$5|T|U|V|A|$W|X]]]]

Yeah, Facade and Service are not entirely unrelated. And some time we implement Service layer as Facade so that client is not bothered about to many details of the service. The more simpler the invocation/interface of a service is the simpler and easier clients code.

The Martin Fowler says...

<blockquote>
 A Service Layer defines an application's boundary [Cockburn PloP] and its set of available operations from the perspective of interfacing client layers. It encapsulates the application's business logic, controlling transactions and coordinating responses in the implementation of its operations
</blockquote>

So services layer is used at times as Facade. 

<a href="http://www.manning-sandbox.com/thread.jspa?messageID=92006" rel="nofollow noreferrer">Ref</a>

blocks|key|5222959|text|从字面上看，立面顾名思义就是指建筑物的正面。路过这条路的人只能看到立面，他们不知道里面是什么，布线，管道和其他复杂情况。这张脸隐藏了建筑的所有复杂性，并显示出一张更简单、友好的脸。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5222960|在软件方面，facade通过提供更简单的界面隐藏了软件组件的复杂性，没有自己的功能，也不限制对substsyem的访问。通常在面向对象设计中使用。SLF4J就是一个很好的例子-它是一个用于日志系统的简单外观，允许最终用户在部署时插入所需的日志系统。|5222961|服务是一个公共接口，它提供对功能单元的访问，并始终按照规范编写。它需要支持其不同使用者所需的通信契约(基于消息的通信、格式、协议、安全性、异常等等)。其中包括流程服务-业务工作流的封装，业务逻辑服务-规则/功能的封装，数据服务-与实体的交互，数据访问管理，基础设施服务-实用功能，如监控，日志和安全。服务大多是可重用的、不相关的、松散耦合的功能单元。|offset|length|style|BOLD|5222962|它们有很多相似之处，但取决于你如何看待它。|5222963|5222964|我看到的不同之处在于，立面是从里到外设计的。您可以查看子系统并设计一个外观来提供更简单的访问。服务是在外部设计的。您可以查看您的客户/客户，定义合同并设计服务。|blockquote|5222965|5222966|entityMap^0|0|0|27|4|2L|6|31|4|3K|6|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|U|8|@$F|V|G|W|H|I]|$F|X|G|Y|H|I]|$F|Z|G|10|H|I]|$F|11|G|12|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|13|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|14|8|@]|9|@]|A|$]]|$1|M|3|N|5|O|7|15|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|R|$]]

Literally, Facade as the name suggests means the front face of the building. The people walking past the road can only see the facade, They do not know anything about what inside it, wiring, the pipes and other complexities. The face hides all the complexities of the building and displays a simpler friendly face.

In software terms, facade hides the complexities of software components behind it by providing a simpler interface, doesn't have the functionality of its own and doesn't restrict the access to the substsyem. Commonly used in Object Oriented Design. 
Good examples are SLF4J - It is an api which is a simple facade for logging systems allowing the end-user to plug-in the desired logging system at deployment time.

A service is a public interface that provides access to a unit of functionality and always written to a specification. It needs to support the communication contracts (message-based communication, formats, protocols, security, exceptions, and so on) its different consumers require.
There is process services - encapsulation of business workflows , business logic service - encapsulation of rules/functions, data services - interaction with entities, data access management, infrastructure services- utility functions such as monitoring, logging &amp; security. Services are mostly reusable, unassociated, loosely coupled units of functionality.

They are lot similar but depends on how you look at it.

<blockquote>
 The difference that I see, Facades are designed inside out. You look
 at subsystem and design a facade to provide simpler access. Services
 are designed outside in. You look at your customer/clients define a
 contract and design the service.
</blockquote>

blocks|key|5706293|text|首先要注意的是，设计模式是使用标准解决方案对常见(设计)问题的描述。在某些情况下，有几种方法可以满足所有需求来解决问题(f.ex。迭代器和单例模式有大量不同的实现；f.ex。检查Alexandrescu的工作并将其与标准的GoF解决方案进行比较)，在某些情况下，相同的(代码)解决方案(f.ex.比较GoF一书中的组合模式和装饰模式的类图)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|5706294|根据GoF的说法，外观模式的目的是(原文引述)：|5706295|5706296|为子系统中的一组接口提供统一的接口。Facade定义了一个更高级别的接口，使子系统更易于使用。|blockquote|5706297|5706298|5706299|服务的目的是向用户提供具有给定功能的单个较高级别的界面。这并不一定使其成为外观，因为严格地说，根据定义，服务不是unified+interface+to+a+set+of+interfaces+in+a+subsystem.|5706300|但是我们可以做得更好，|BOLD|5706301|你的问题是这些模式是否“相似”。当模式A等于B，模式B等于A时，如果我们认为它们“相似”，那么我们应该回答两个问题：|5706302|问题1:+is+a+Service+a+Facade？服务绝对应该公开功能，并且绝对是公开此功能的单个接口。功能通常被分解成很小的部分，所以是的，服务符合外观的底层需求。换句话说:面对将底层接口公开为统一的“服务”接口的问题，外观模式符合需求，并用于解决服务问题。这个问题的答案是，是的，。|5706303|问题2:+is+a+Facade+a+Service？服务通常被设计为可重用的、不相关的、松散耦合的功能单元。考虑组件之间的通信对于服务很重要，因为它们通常依赖于TCP/IP接口，如SOAP或WCF。这也意味着功能经常被重写以更贴近services范例，这为模式添加了由performance需求驱动的隐式。外观没有这个额外的要求。换句话说：外观不是服务。|5706304|准确地说，这些概念是密切相关的，但不是相同的。|5706305|，但我们可以做得更好|5706306|这种思路提出了这样一个问题：服务是否是外观的扩展版本？它是如果服务满足外观的所有要求并在此基础上进行扩展的话。|5706307|如果你仔细阅读GoF的描述，答案是肯定的，那就是:如果满足一个条件:服务必须公开子系统。在现实中，我认为这种情况通常成立，或者您过度设计您的服务-尽管严格地说，我认为这不是一个严格的限制。|5706308|entityMap^0|2H|C|0|0|0|0|0|0|1K|1K|0|0|B|0|0|0|4|3W|4|A|7|K|6|0|0|4|49|P|A|6|J|7|38|8|0|0|N|0|0|A|0|0|1J|0|0|2M|0^^$0|@$1|2|3|4|5|6|7|18|8|@$9|19|A|1A|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1B|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|1C|8|@]|D|@]|E|$]]|$1|I|3|J|5|K|7|1D|8|@]|D|@]|E|$]]|$1|L|3|-4|5|6|7|1E|8|@]|D|@]|E|$]]|$1|M|3|-4|5|6|7|1F|8|@]|D|@]|E|$]]|$1|N|3|O|5|6|7|1G|8|@$9|1H|A|1I|B|C]]|D|@]|E|$]]|$1|P|3|Q|5|6|7|1J|8|@$9|1K|A|1L|B|R]]|D|@]|E|$]]|$1|S|3|T|5|6|7|1M|8|@]|D|@]|E|$]]|$1|U|3|V|5|6|7|1N|8|@$9|1O|A|1P|B|R]|$9|1Q|A|1R|B|R]|$9|1S|A|1T|B|C]|$9|1U|A|1V|B|C]]|D|@]|E|$]]|$1|W|3|X|5|6|7|1W|8|@$9|1X|A|1Y|B|R]|$9|1Z|A|20|B|R]|$9|21|A|22|B|C]|$9|23|A|24|B|C]|$9|25|A|26|B|C]]|D|@]|E|$]]|$1|Y|3|Z|5|6|7|27|8|@$9|28|A|29|B|R]]|D|@]|E|$]]|$1|10|3|11|5|6|7|2A|8|@$9|2B|A|2C|B|R]]|D|@]|E|$]]|$1|12|3|13|5|6|7|2D|8|@$9|2E|A|2F|B|R]]|D|@]|E|$]]|$1|14|3|15|5|6|7|2G|8|@$9|2H|A|2I|B|R]]|D|@]|E|$]]|$1|16|3|-4|5|6|7|2J|8|@]|D|@]|E|$]]]|17|$]]

The first thing to note is that a design pattern is a description for a common (design) problem with a standard solution. In some cases there are several ways to solve the problem in a way that fits all requirements (f.ex. the Iterator and Singleton patterns have tons of different implementations; f.ex. check the work of <code>Alexandrescu</code> and compare it with the standard GoF solutions) and in some cases there are different patterns with the same (code) solution (f.ex. compare the class diagrams of the Composite and the Decorator patterns in the GoF book). 

According to the GoF the purpose of the Facade pattern is to (literal quote):

<blockquote>
 Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher level interface that makes the subsystem easier to use.
</blockquote>

Services have the intention of providing a user with a single higher level interface with a given functionality. That doesn't necessarily make it a facade, because a service is strictly speaking not by definition a <code>unified interface to a set of interfaces in a subsystem.</code>

But we can do better than that

Your question was if the patterns are "similar". If we consider them to be "similar" when pattern A equals B and pattern B equals A, then we should answer 2 questions:

Question 1: is a <code>Service</code> a <code>Facade</code>? A service should definitely expose functionality and is definitely a single interface that exposes this functionality. Functionality is normally decomposed into tiny pieces, so yes, services fit the underlying requirements of a facade. In other words: faced by the problem of exposing the underlying interfaces as a unified "service" interface, the facade pattern fits the requirements and is used to solve the service problem. The answer to this is yes.

Question 2: is a <code>Facade</code> a <code>Service</code>? Services are normally designed as reusable, unassociated, loosely coupled units of functionality. Thinking about communication between components is important for services, because they usually rely on a TCP/IP interface such as SOAP or WCF. This also means that functionality is often rewritten to fit the <code>services</code> paradigm more closely, which adds an implicit driven by performance requirement for the pattern. Facades don't have this extra requirement. In other words: a facade is not a service.

In exact terms, these concepts are closely related, but not the same.

But we can do better

This line of thinking raises the question if a service is an extended version of a facade? It is if a service meets all the requirements of a facade and extends on top of that. 

If you read the description by the GoF closely, the answer is yes, that is: if one condition is met: The service has to expose subsystems. In reality, I think this condition normally holds, or you're over-designing your services - though strictly speaking I suppose this is not a hard restriction.

blocks|key|699467|text|在我尝试回答之前，让我澄清一些事情:企业应用程序中有三个截然不同的东西-外观、服务层和远程外观。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|699468|Facade+-虽然包装了子系统，但仍然是一个对象和UI+(MVC)应用程序，通常位于同一进程中。因此，通信是以一种常见的面向对象方式完成的:调用方法、读取属性、侦听事件。|699469|服务层--当业务逻辑层变得成熟和复杂，以至于不能直接与之交互时，就把服务层放在它们之间。服务层是MVC用作业务逻辑包装器的API。它不是远程的，也不需要使用DTO，因为通信中不涉及任何线路。|699470|Remote+Facade+-(简单地说，任何远程服务)这是外观层和服务层的混合。当您想要在系统上公开某种包装器(我们称之为Facade)作为分布边界时，远程Facade就开始存在了。其中一个原因可能是允许多个UI+(MVC)应用程序使用相同的远程外观。|699471|-|699472|Comparisons:|699473|外观与服务层：它们很相似，因为它们都包装了子系统。不同之处在于，服务层更多地面向UI+(MVC)应用程序需求，并公开功能以简化业务逻辑的工作。另一方面，Facade公开功能以简化业务逻辑，但不一定简化与UI+(MVC)应用程序的通信。|699474|外观与远程外观(服务？)：绝对不同，因为远程外观必须使用DTO作为通信消息。如果您仍然希望将远程外观用作常规对象(属性、事件)，则远程外观将需要某种类型的代理；但代理无论如何都会使用对真实对象的DTO，即远程外观。|699475|699476|可能的流：|699477|controller-facade-dao+-值得怀疑，但仍有可能。Facade通常不是用来包装DAL的。除了作为子系统之外，还应该有一些更成熟的东西。但是，如果facade是业务逻辑的一部分，那么是的，这是可能的。尽管如此，必须更加强调子系统。对我来说，DAL包装还不足以称之为Facade。|CODE|699478|controller-service-dao+-绝对有可能。许多远程服务通过DAL直接与数据库打交道。|699479|controller-facade-service-dao+-也许吧，如果你把服务当做一个子系统来对待的话。|699480|我想再加一个可能有意义的：|699481|controller-service+[layer]-facade+(part+of+business)-subsystem+(e.g.+accounting,+business+on+its+own)-dao+-我相信你可以把它翻译过来。|699482|699483|请记住，服务(或远程外观)可以存在于流中的任何位置。这是由您的发行版需求决定的。|699484|entityMap^0|10|2|13|3|17|4|0|0|6|0|0|M|0|0|D|0|0|0|C|0|0|2|3|3|0|0|2|3|9|0|0|0|5|0|0|L|0|0|M|0|0|T|0|0|0|2X|0|0|0^^$0|@$1|2|3|4|5|6|7|1C|8|@$9|1D|A|1E|B|C]|$9|1F|A|1G|B|C]|$9|1H|A|1I|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1J|8|@$9|1K|A|1L|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1M|8|@$9|1N|A|1O|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|1P|8|@$9|1Q|A|1R|B|C]]|D|@]|E|$]]|$1|L|3|M|5|6|7|1S|8|@]|D|@]|E|$]]|$1|N|3|O|5|6|7|1T|8|@$9|1U|A|1V|B|C]]|D|@]|E|$]]|$1|P|3|Q|5|6|7|1W|8|@$9|1X|A|1Y|B|C]|$9|1Z|A|20|B|C]]|D|@]|E|$]]|$1|R|3|S|5|6|7|21|8|@$9|22|A|23|B|C]|$9|24|A|25|B|C]]|D|@]|E|$]]|$1|T|3|M|5|6|7|26|8|@]|D|@]|E|$]]|$1|U|3|V|5|6|7|27|8|@$9|28|A|29|B|C]]|D|@]|E|$]]|$1|W|3|X|5|6|7|2A|8|@$9|2B|A|2C|B|Y]]|D|@]|E|$]]|$1|Z|3|10|5|6|7|2D|8|@$9|2E|A|2F|B|Y]]|D|@]|E|$]]|$1|11|3|12|5|6|7|2G|8|@$9|2H|A|2I|B|Y]]|D|@]|E|$]]|$1|13|3|14|5|6|7|2J|8|@]|D|@]|E|$]]|$1|15|3|16|5|6|7|2K|8|@$9|2L|A|2M|B|Y]]|D|@]|E|$]]|$1|17|3|M|5|6|7|2N|8|@]|D|@]|E|$]]|$1|18|3|19|5|6|7|2O|8|@]|D|@]|E|$]]|$1|1A|3|-4|5|6|7|2P|8|@]|D|@]|E|$]]]|1B|$]]

Before I try to answer, let me clarify something: there are three distinct things in enterprise applications - Facade, Service Layer, and Remote Facade.

Facade - while wrapping the subsystem(s), still is an object and UI (MVC) application usually lives in the same process. Thus, the communication is done in an usual OO manner: calling methods, reading properties, listening to the events.

Service Layer - when the business logic layer becomes mature and too complex for the MVC to interact with it directly, then Service Layer is put between them. Service Layer is an API that MVC uses as a wrapper of the business logic. It is not remote and is not required to use DTO since no wire is involved in the communication.

Remote Facade - (simply, any remote service) this is a hybrid of the Facade and Service Layer. Remote Facade starts existing when you want to expose some kind of wrapper over the system (and we call it Facade) as a distribution boundary. One of the reasons can be to allow several UI (MVC) applications use the same Remote Facade.

-

Comparisons:

Facade vs. Service Layer: they are similar since both they wrap subsystems. Difference is that Service Layer is more oriented on UI (MVC) application needs and exposes functions to simplify working with business logic. On the other hand, Facade is exposing functionality to simplify the business logic, but does not necessarily simplify the communication with UI (MVC) application.

Facade vs. Remote Facade (Service?): definitely different since Remote Facade must use DTOs as communication messages. Remote Facade will need some kind of proxy if you still want to use it as a regular object (properties, events); but the proxy will anyway use DTOs to the real object, i.e. Remote Facade.

-

Possible Flows:

<code>controller-facade-dao</code> - doubtful, but still possible. Facade is not usually used to wrap just DAL. There should be something more mature in addition as a subsystem. But, if the facade is part of the business logic, then yes, this is possible. Still the subsystem must be more emphasized. To me, DAL wrapping is not enough to call it Facade.

<code>controller-service-dao</code> - absolutely possible. Many remote services work directly with database through DAL.

<code>controller-facade-service-dao</code> - maybe, if you treat service as a subsystem.

I would add one more that can make sense:

<code>controller-service [layer]-facade (part of business)-subsystem (e.g. accounting, business on its own)-dao</code> - I'm sure you can translate this.

-

Remember, Service (or remote facade) can exist anywhere in the flow. That is just dictated by your distribution needs.

blocks|key|1872271|text|我对经典的GoF外观模式的理解是，它主要是为了隐藏一个糟糕的设计。作为一个经验法则，我想说的是，人们应该只需要一个外观来处理遗留代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1872272|我还认为，此模式之所以成为J2EE核心模式(会话外观)，主要是因为EJB规范(至少2.x版)本质上导致了糟糕的服务层设计。|1872273|因此，我对您的问题的回答是肯定的--+facade实际上是一种第一次没有正确实现的服务。如果您需要对客户端代码隐藏复杂性，这通常意味着您只设法提供了一个库，而不是服务层；因此，在这种情况下，Facade实际上成为了您的服务层。|1872274|另一方面(假设您有一个像样的域层)，如果您确实需要提供通过单个方法调用(类似宏/别名)生成复杂流的选项，这通常会更好地放在应用程序层而不是您的核心域中--请注意，我已经将分层术语切换为域驱动设计，其中没有“数据访问”或“服务”层，而是“应用程序”、“域”、“基础结构”。|1872275|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

My understanding of the classical GoF Facade pattern is that it's mainly intended to hide a poor design. As a rule of thumb, I would say that one should only need a Facade for legacy code.

I also think that this pattern made its way as a J2EE core pattern (Session Facade) mainly because the EJB spec (at least up to 2.x) inherently resulted in a poor service layer design.

Therefore, my answer to your question would be yes -- a facade is actually a service that hasn't been properly implemented the first time. If you need to hide the complexity from client code, it usually means that you only managed to provide a library, not a service layer; so, in this case, the Facade actually becomes your service layer.

On the other hand (assuming you have a decent domain layer), if you really need to provide the option of spawning complex flows with a single method call (something resembling macros/aliases), this would usually be better placed in the application layer and not in your core domain -- notice that I've switched layering terminology to domain driven design, where there's no "data access" or "service" layer, but "application", "domain", "infrastructure".

blocks|key|5706466|text|外观和服务层有一些相似之处，但它们都有两个不同的含义。让我用一个简单的例子来解释一下。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|5706467|假设我们被要求创建新的业务应用程序。这需要创建一个签到应用程序，但具有更多的增值功能和忠诚卡功能。|5706468|假设应用程序应该支持Facebook和Foursquare签到功能，如果用户想使用的话。这个功能是非常需要的，因为一些用户不愿意使用多个应用程序来做相同的功能，或者摆脱社交连接。|5706469|要了解更高层次的概念，请参阅以下链接https://docs.google.com/file/d/0B3v8S0e-PvVpdWFJOVhqc1d2SHc/edit?usp=sharing上的示例api|5706470|上述位于ABC+Facade的check-in+API是一个使用facade的示例。|5706471|它有我们的服务API，也有基于客户选择的facebook和foursqure签到功能。Facebook和foursqure+API可以有特定的实现(SOAP、Restful等)和安全性(OAuth等)需求等。|5706472|满足这些API+(facebook、foursqure)之一的需求需要完成不同的任务集。在我们的签入需求中，这些将是不同的子系统。|5706473|因此，facade的简单用法是满足由一种简单方法触发的多个子系统|5706474|但是如果我们考虑我们自己的应用程序接口，那就是位于MngCheckinSvc的签入应用程序接口。这是一个服务层应用程序接口。这是包含我们的应用程序的签入需求的API。这是提供从您MngCheckinSvc公共访问的API，用于处理应用程序的签入要求。|5706475|这将具有复杂的内部行为，但大多数仍将是特定于应用程序的逻辑实现。|5706476|本接口(MngCheckinSvc.checkin(....))可以访问不同的DAO集，内部API，可以是其他内部服务等，以便在应用程序中实现商家签到。|5706477|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.google.com/file/d/0B3v8S0e-PvVpdWFJOVhqc1d2SHc/edit?usp=sharing^0|0|2|3|3|0|0|0|I|24|0|0|0|0|0|0|1G|9|0|0|0^^$0|@$1|2|3|4|5|6|7|17|8|@$9|18|A|19|B|C]|$9|1A|A|1B|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1C|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|1D|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|1E|8|@]|D|@$9|1F|A|1G|1|1H]]|E|$]]|$1|L|3|M|5|6|7|1I|8|@]|D|@]|E|$]]|$1|N|3|O|5|6|7|1J|8|@]|D|@]|E|$]]|$1|P|3|Q|5|6|7|1K|8|@]|D|@]|E|$]]|$1|R|3|S|5|6|7|1L|8|@]|D|@]|E|$]]|$1|T|3|U|5|6|7|1M|8|@$9|1N|A|1O|B|C]]|D|@]|E|$]]|$1|V|3|W|5|6|7|1P|8|@]|D|@]|E|$]]|$1|X|3|Y|5|6|7|1Q|8|@]|D|@]|E|$]]|$1|Z|3|-4|5|6|7|1R|8|@]|D|@]|E|$]]]|10|$11|$5|12|13|14|E|$15|16]]]]

Facade and Service Layer has kind of a similarity but both of them has two distinguished meanings. Let me explain this using a simple example.

Imagine we are asked to create new business application. This has a requirement of creating a check-in application but with more value added features and loyalty card features.

Lets say application should support Facebook and Foursquare check-in features if user wish to use. This feature is very much needed because some users are reluctant use several applications doing the same function or get rid of social connectivity.

to get a highlevel idea, refer sample api on the following link <a href="https://docs.google.com/file/d/0B3v8S0e-PvVpdWFJOVhqc1d2SHc/edit?usp=sharing" rel="nofollow">https://docs.google.com/file/d/0B3v8S0e-PvVpdWFJOVhqc1d2SHc/edit?usp=sharing</a> 

Above check-in API located at ABC facade is an example for usage of Facade.

It has our service API and also facebook and foursqure check-in capabilities based on client's selection. Facebook and foursqure APIs can have specific implementations (SOAP, Restful, etc. ) and security (OAuth etc.) requirements etc.

Satisfying one of these APIs (facebook, foursqure) requirements needs to fulfil different set of tasks. these will be different sub systems with in our check in requirement.

So facade's simplistic usage is to satisfy several sub systems triggered by one simple method

But if we consider our own API which is check-in API located at MngCheckinSvc. This is a service layer API. This is the API that contains our application's check in requirements. This is the API provide public access from your MngCheckinSvc to handle check-in requirement to application.

This will have complex inner behaviors but still most of them will be application specific logic implementations.

This API(MngCheckinSvc.checkin(....)) might access different set of DAOs, Internal APIs, may be other internal services etc. in order to fulfill merchant check-in with in the application.

blocks|key|5706501|text|FACADE是一种设计模式，它解决了子系统中的许多接口需要统一接口的问题，因此它定义了一个更高级别的接口，使子系统更易于使用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5706502|然而，服务提供对资源或一组接口/对象的访问，并且不一定简化这样的访问。因此，您可以使用外观模式来更好地设计您的服务，这样就可以省去客户端计算如何构造来使用它的麻烦。|5706503|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

FACADE is a design pattern which solves the problem where there is a need for a unified interface to many interfaces in a subsystem so it defines a higher-level interface that makes the subsystem easier to use.

HOWEVER, A SERVICE provides access to resources or a set of interfaces/objects and may not necessarily simplify such an access. So you can employ the facade pattern to better design your service so you can save the client figuring out how to construct to use it.

The more I read, the more confused I am. 

Note that all the question is related to how service and facades fit on the MVC pattern.

My understanding is that a Facade is not a super-smart object, it is simply a way of exposing a simple interface/api to perform a complex operation (example: perform a 10$ payment, it is a complex operation that involves a number of operations, but such complexity can be handled by a facade which will just call the corresponding object in a particular order...etc...)

Now, a service is a way to perform calls to several DAOs in order to get complex data structures (I am not too sure of this, but it is what I understand so far).

Question then is, what is the difference between a facade and a service? At the end of the day, the facade can perfectly access several DAOs in order to perform a complex operation by providing a simple interface, and a service seems to to something similar.

Same happens with transactions, I understand that a service is the place to start transactions, but I equally feel that they could also be placed on facades, after all, a facade may call several DAOs too. 

So which stack would make more sense

controller-facade-dao 
controller-service-dao

or maybe

controller-facadade-dao AND sometimes controller-facade-service-dao ??

Are the roles of a service and a façade similar?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我读得越多，我就越困惑请注意，所有问题都与服务和外观如何适应MVC模式有关。我的理解是，外观不是超级智能的对象，它只是一种公开简单接口/api来执行复杂操作的方式(例如:执行10美元支付，这是一个涉及多个操作的复杂操作，但这种复杂性可以由外观处理，它只会调用特定order...etc中的相应对象……)现在，服务是一种执...

问服务和立面的角色相似吗？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问服务和立面的角色相似吗？EN