Pro ADO.NET Data Services：RESTful数据应用深度解析

需积分: 0 169 浏览量更新于2024-07-17 收藏 2.97MB PDF 举报

《Pro ADO.NET Data Services: Working with RESTful Data》是由John Shaw和Simon Evans合著的一本专业书籍，专注于在.NET平台上利用ADO.NET技术处理RESTful数据。这本书于2009年出版，版权由作者和出版社共同持有，强调了在未经许可的情况下复制或传播内容是非法的。 ADO.NET（ActiveX Data Objects for .NET）是Microsoft为.NET框架提供的用于访问数据库的强大工具集，它允许开发人员以一种面向对象的方式与各种数据源进行交互，包括关系型数据库、XML文件和Web服务。在《Pro ADO.NET Data Services》中，作者深入探讨了如何利用ADO.NET构建RESTful数据服务，这是一种基于HTTP协议的架构风格，强调资源的标识、状态转移和无状态性，常用于现代web应用中。 RESTful设计原则包括使用标准HTTP方法（GET、POST、PUT、DELETE等）、URI表示资源、以及通过HTTP头提供元数据等。书中可能会详细介绍如何使用ADO.NET Data Services（ADO.NET的扩展，可能包括ADO.NET Entity Framework或ADO.NET Web API）来实现这些原则，例如如何创建和操作数据上下文、执行CRUD操作（Create, Read, Update, Delete），以及处理分页、排序和过滤等常见的RESTful场景。作为一本技术详尽的著作，该书不仅涵盖理论概念，还提供了实践指导和示例代码，帮助读者理解和掌握如何在实际项目中利用ADO.NET搭建高效、可扩展的RESTful数据服务。此外，书中还可能涉及安全性、性能优化和故障处理等相关话题，确保开发人员能够构建健壮的API接口。该书的技术审查者Damien Foggon的参与，表明内容经过了严格的同行评审，确保了信息的准确性和实用性。本书适合.NET开发者、Web服务开发者和架构师阅读，特别是那些想要将传统数据库技术与现代Web服务设计相结合的专业人士。无论是初学者还是经验丰富的开发人员，都能从中受益匪浅，提升其在处理RESTful数据方面的技能。

xvii

Acknowledgments

I would like to thank my partner, Angharad, for her continuous help and support throughout

the highs and lows of writing this book. I would also like to thank my parents for buying me my

first computer at the age of eight and helping me learn to program it. Without this investment,

I would not be in my chosen career.

Several people have helped in reading and providing opinion on the content of this book.

Beyond everyone at Apress who have turned a rambling text into a coherent body of work, I

would also like to thank my colleagues at Conchango who have provided valuable opinion. In

particular I would like to thank Owain Wragg for providing an extra pair of eyes over much of

the content of this book.

Simon Evans

I would like to thank my wife, Lori, for her love and support and her inspiration. Thanks also

to my family and friends who have stuck by me over the years, particularly my parents, who

helped me emerge from a little-known town called Warrington. Similar to Simon’s parents,

mine bought me a ZX spectrum when I was five years old, providing a solid programming

foundation.

Additionally, I would like to thank Mark Beckner, Damien Foggon, Ami Knox, and the rest

of the team at Apress, as well as Mike Taulty and Jon Flanders, who provided valuable early

insights into ADO.NET Data Services. Lastly I would like to thank the Astoria team, particularly

Pablo Castro and Mike Flasko, who have put together a great piece of software.

John Shaw

CHAPTER 1

The Foundations of ADO.NET

Data Services

Software development is hard; one year in development is equivalent to a dog year’s worth

of change. The problem of rapid change is exacerbated by those in the industry who inces-

santly call the latest innovation the silver bullet that will solve the world’s ills. While this is

never the case, innovations in technology, if used appropriately, do deliver better solutions

that improve the bottom line of the businesses we serve.

Underpinning technology innovations are concepts, which evolve at a much slower rate

than the specifics of a new technology. Concepts help us solve many of the requirements that

are common to most of the solutions that we as software developers have to deliver in the

enterprise.

ADO.NET Data Services is a new technology designed to meet one of the most common

requirements in software development: access to data over a network. Developers use three

key concepts to meet this requirement, each of which we’ll discuss in this chapter:

 s 4HECONCEPTOF set- based logic to access data from a data source

 s 4HECONCEPTOFobject orientation to apply business logic to data

 s 4HECONCEPTOFservice orientation to communicate data using messages across

a network

This chapter will describe the key Microsoft technologies that apply to using these con-

cepts and explore how ADO.NET Data Services builds on top of these foundations to make

working with data over a network more productive than ever before.

The Concept of Set- Based Logic

Set-based logic is about solving a problem in terms of sets of data, where a set of data is defined

by statements that limit, group, and order the data in the set. For example, you may wish to

retrieve a set of customers where the customers’ first names equal “Joe” and order the set of

customers by their last names. When developers think of set- based logic, they normally think

of Structured Query Language (SQL), which is the most common way of implementing set- based

logic. A limitation of SQL as a technology is that it is only used to retrieve data from a data source

(usually a relational database) such as SQL Server. To give developers a way to carry out set- based

operations in code, Microsoft introduced Language Integrated Query (LINQ) in .NET 3.5, which

CHAPTER 1 N THE FOUNDATIONS OF ADO.NET DATA SERVICES

applies the concept of set- based logic to work with all forms of data, whether the information

comes from SQL Server or XML, or is in memory.

Under the covers, LINQ uses technologies such as SQL to work with data from the data source,

but it abstracts the need for developers to learn several technologies when they have to perform

set- based logic. Flavors of LINQ include LINQ to Objects, LINQ to SQL, and LINQ to XML.

The Concept of Object Orientation

Whereas set- based logic is used to access data, object orientation is used to provide a repre-

sentation of that data to some real- world entities (objects). The reason that object orientation

is so important to writing maintainable solutions is that the representation of data as it is

stored in a database does not describe the behavior of that information. For example, you

could have customers modeled in a ?qopkian table in SQL Server, each with a customer type,

such as buyer and vendor. Clearly, some ways in which you need to interact with buyers and

vendors will be the same, as they are both customers; but in other ways, the business rules you

use with buyers may well differ from those customers who are vendors. For example, you may

want to provide vendors with access to sales on your web site, but this information must be

withheld from buyers because it is sensitive information. Yet both buyers and vendors would

need to log in to the web site, so business rules dealing with authentication and authorization

would need to apply to all customers.

Object orientation allows both buyer and vendor entities to inherit from a base customer

entity, meaning that they can both behave as customers, but also extend this common behav-

ior with buyer- or vendor- specific properties and methods. Figure 1-1 shows this principle,

with the >quan and Raj`kn classes inheriting from the ?qopkian abstract class. The >quan and

Raj`kn classes extend the base class, each adding a property and method associated with how

buyers and vendors handle products. Without object orientation, it would not be possible to

treat both the >quan and Raj`kn objects as customers.

Figure 1-1. Simple example of the object- oriented principle of inheritance

In moving between data as it is structured in a relational database and entities, there is

clearly a need to map the data between its representation in a table and its representation in

an entity. This difference in structure is sometimes referred to as an impedance mismatch.

Traditionally, this problem would have been solved by writing mapping code in the data

access layer, but recent innovations have led to the use of object relational mappers to per-

form the mapping between databases and objects. By using object relational mapping, the

CHAPTER 1 N THE FOUNDATIONS OF ADO.NET DATA SERVICES

developer does not need to write tedious code to achieve this aim. Several object relational

mappers are available to .NET developers, such as NHibernate, but this book will focus on

Microsoft’s own ADO.NET Entity Framework, because of its close relationship with ADO.NET

Data Services and LINQ, using LINQ to Entities.

The Concept of Service Orientation

With set- based logic helping us access data and object orientation helping us implement busi-

ness logic on that data, the final problem that needs to be solved in order to meet the original

requirement is moving this data across a network. The concept of service orientation deals

with this requirement by communicating data in discrete messages between a sender and

a receiver application. The sender is commonly called the client or proxy and the receiver is

the service.

The sent messages must conform to a contract dictated by the service. The contract defines

exactly what structure of data is accepted by the service and how the data can be used. The

format (such as XML) and encoding (such as text) of the message may differ, and the low- level

protocol (transport) used for communication may differ also; however, by considering com-

munication of data as encoded messages being sent and received over a transport using a set

contract, service orientation loosely couples the sender and receiver, and acknowledges that

the technology implementation of the transport and encoding may change over time. Indeed, we

may also want to use different transports and encodings for different clients. For example, we may

want to expose a service to external customers over the Internet using the Hypertext Transfer

Protocol (HTTP) transport with a text encoding, but internally we may want to communicate

using TCP/IP and a binary encoding, because internally we have control of the development of

our own clients and the security of our network.

In .NET, the concept of service orientation is delivered using Windows Communication

Foundation (WCF), and ADO.NET Data Services is built on top of this foundation. WCF is

described in detail later on in this chapter in the section “The ABCs of Windows Communica-

tion Foundation.”

RESTful Thinking

If you have designed components or services in the past, you are most likely to have devel-

oped an interface or service contract, where you define what operations a component is

allowed to perform. For example, you might design a contract that contains three opera-

tions: CapLnk`q_p>uE`( LanoeopLnk`q_p, and @ahapaLnk`q_p. Each of these operations deals

with a product entity and defines what you can do with a product. In other words, each

operation is a verb, and it deals with the product entity, which is a noun.

Why do we write service contracts containing operations describing what a client can

do with the service? It is because there is commonly no other mechanism for understanding

how a service can be consumed. But the majority of web services use HTTP as their transport.

This protocol specifies HTTP verbs that must be sent in the request message. Therefore, if we

are only exposing our service over HTTP, it is possible to use the protocol itself to understand

the intent. This is the architecture proposed by Roy Fielding when he first described a style of

service- oriented architecture (SOA) known as representational state transfer (REST).

剩余326页未读，继续阅读

rybhgr

粉丝: 2
资源: 8

Pro ADO.NET Data Services：RESTful数据应用深度解析

ADO.NET Data Services：RESTful数据处理指南

ADO.NET数据服务实战：RESTful数据交互

精通ADO.NET Entity Framework 4.0

Pro ADO.NET Data Services Working with RESTful Data

Apress - Pro ADO.NET Data Services Working with RESTful Data

Pro ADO.NET Data Services: Working with RESTful Data

Professional ADO.NET 2: Programming with SQL Server 2005, Oracle, and MySQL 书配代码

[ASP.NET.3.5高级程序设计(第2版)].Pro.ASP.NET.3.5.in.C#.2008.2th.edtion part 1

[ASP.NET.3.5高级程序设计(第2版)].Pro.ASP.NET.3.5.in.C#.2008.2th.edtion part 2

Pro C# 7: With .NET and .NET Core

最新资源