使用My命名空间简化.NETFramework程序设计.ppt

* * * * * * * * * * * * * * * * * * * * Speaker Notes Tenet 1: Boundaries are Explicit. Based on the underlying concept of encapsulation, this tenet specifies the publishing and consumption of functionality as sets of services that abstract their underlying implementation. With Indigo, the attribute-based programming enables developers to explicitly define external service contracts. Without explicitly defining these, nothing within the class will be exposed publicly. In other words, Indigo provides an opt-in model for explicitly defining service boundaries. Tenet 2: Services are Autonomous. Autonomy means we design the system to support the inevitable evolution of the service’s implementation over time. As we build our services, we need to assume that their internal implementation will evolve (be versioned) over time and that our services as well as the services on which we depend could change location at (almost) any time. Tenet 3: Services share schema and contract, not class. For those of you who are familiar with ASMX - this is exactly how ASMX works: The service publishes a contract that clients use to generate their own code to call the service. No types are shared between service and its clients by default. In addition, neither Service requires knowledge of each others’ internal workings in order to exchange data – they only need the published schemas contracts Tenet 4: Service compatibility is determined based on policy. The services communicate through dynamically negotiated communications channels that support the necessary semantics (security, reliability, etc). Service policy statements created automatically based on configuration, class attributes, and method signatures. Client channels automatically configured via retrieved service policy. By “name” means that we reference a well known name in Policy that represents a whole specification of behavior that needs to be used when talking to this endpoint. Transition to next slide: Buildin