Search

Web services provide a way to run a service on the Web and access its methods using standard protocols, including Simple Object Access Protocol (SOAP), Exten­sible Markup Language (XML), Web Service Description Language (WSDL), and Hypertext Transfer Protocol (HTTP). Technically, a Web service is nothing more than an application that exposes its interface over the Web to a client who wants to access the service’s abilities. The uses of aWeb service include validating credit cards, searching for data in a database, inserting an order into a shopping cart, and updating a guest list. The sky is the limit on what you can have your Web service do on your server.

In the last chapter you learned the basics of turning the data in your database into objects. Although basic Object-Relational (OR) mapping is simple, a number of issues become apparent when it comes time to actually put it to work.

ActneX Data Objects for the .NET Framework (ADO.NET) is the latest database access technology from Microsoft. ADO.NET addresses issues with previous database access technologies and provides the foundation for future scalability. Although ADO.NET stands for Active Data Objects .NET, it’s perhaps misnamed because unlike ActiveX Data Objects (ADO), ADO.NET isn’t an ActiveX/Component Object Model (COM) technology. As the business world is moving onto the Internet, one of the main goals of ADO.NET is allow developers to write high-performance, reliable, and scalable database applications over the Internet. ADO.NET uses .NET Common Language Runtime (CLR) services to manage the library, and it utilizes Extensible Markup Language (XML) to cache the data and exchange data among applications over the Internet as well as intranets.

In chapter 3, you encountered constraints and data relations. In this chapter, we discuss constraints and data relations in more detail. First, we start this chapter with a discussion of constraints and how ADO.NET constraint objects maintain data integrity. Second, we discuss data relations. An object that encapsulates a data relationship may be a new concept for many programmers.

When it comes to developing interactive database applications, it’s difficult to resist using data-bound controls. Data-bound controls are easy to use, and they also provide many handy, built-in features. You used DataGrid, ListBox, and other data-bound controls in the previous chapters. In this chapter, we discuss the basics of data binding, how to use data-bound controls, and how to develop interactive database applications using these controls with a minimal amount of time and effort.

Chapter 14 discussed the basics of data binding in Web Forms and ASP.NET data-bound controls. You also saw how to use data-bound controls in Web applications. Chapter 15 discussed how to develop data-driven Web services and how to access the functionality implemented in a Web service from Web Forms applications. This chapter is an extension of Chapter 14. This chapter concentrates on the more practical aspects of data binding and Web Forms data-bound controls.

The Component Object Model (COM) has been around for many years and is used by many Windows applications. Eventually the .NET platform will replace COM, but until then you may need to develop COM components from .NET and access them from unmanaged code, or you may want to use COM components in .NET applications. COM interoperability (also referred to as COM Interop) enables you to use existing COM components in .NET applications or use.NET components in unmanaged code.

Relational databases such as SQL Server and Oracle rely on stored procedures to do repetitive tasks, so a programmer’s main jobs when creating database applications are creating, debugging, and testing stored procedures (often called stored procs). Another database object it behooves programmers to learn is the view—or virtual table. In this chapter, you’ll learn how to take advantage of Visual Studio.NET (VS.NET) tools to work with both stored procedures and views.

The programming world is moving more and more toward the Web, and Extensible Markup Language (XML) is an essential part of Web-based programming. This chapter assumes you have an understanding of basic XML syntaxes and documents.

Chapter 14 discussed the basics of ASP.NET and how to write data-driven Web applications using ASP.NET and ADO.NET. Chapter 16 discussed data binding in ASP.NET and ASP.NET server controls and how to use these controls to develop data-bound Web applications.

Effective exception and error handling is one of the most important things to learn in order to write reliable and error-proof applications. In this chapter, we discuss how to use the exception and error handling classes provided by the.NET Framework.

ADO.NET allows developers as much flexibility in creating custom data providers as Microsoft had developing the Sg1Client and OleDb data providers. In other words, you can create data providers for virtually any source of data you can think of, from file formats to Web services.

In Chapter 1 and Chapter 2, you learned about ADO.NET, and you learned how to use ADO.NET components with Visual Studio (VS) .NET. You also learned how to write code that binds ADO.NET components to data-bound controls and how to use VS. NET’s Integrated Development Environment (IDE) wizards to write full-fledged database applications.

Ever since the early days of relational databases, optimizing database performance has always been as much an art as a science. Even today, you’ll often hear of new “secrets” through professional relationships that take on the air of furtive back-alley exchanges more reminiscent of a Le Carre novel than a sober discussion between colleagues. This chapter discusses some SQL Server and ADO.NET performance issues. It also discusses some best practices to make sure you get the most out of your code.

Relational databases treat data in terms of rows and columns, and objects treat things in terms of arrays and properties. Object-relational mapping (OR mapping) bridges these two worlds so your code can look like object code and still store itself in a relational database.