Beginning ASP.NET 4.5 Databases
Abstract
Beginning ASP.NET 4.5 Databases introduces you to the world of building data-driven Web sites using ASP.NET, ADO.NET and the Entity Framework using C#. Since ASP.NET developers need to access databases quickly and efficiently, this book teaches the best practices and methods to help developers achieve professional ASP.NET and database solutions. Beginning ASP.NET 4.5 Databases is a comprehensive introduction on how you can connect a Web site to many different data sources not just databases and use the data to create dynamic page content. It also shows youhow to build a relational database, use SQL to communicate with it, and understand how they differ from each other. With in-depth, on-target coverage of the new data access features of .NET Framework 4.5, this book is your guide to using ASP.NET to build responsive, easy-to-update data-driven Web sites. What youll learn Design for code-first, model-first and database-first data access paradigms Use different data sources for building data-driven Web sites Discover enhancements in SQL Server 2012 as a relational database Understand concepts of non-relational databases and why you need them Develop strategies for building Entity Data Models using Entity Framework 4.1 Begin to use the new data-access features in ASP.NET 4.5 like strongly typed controls, model binding and dynamic data Who this book is for Beginning ASP.NET 4.5 Databases is for the web developer who is beginning to get into the world of web development using ASP.NET, ADO.NET and C#. The book is an excellent choice for developers who are still using previous versions of the .NET Framework and who are looking to learn the new data access features in .NET Framework 4.5. Table of Contents ASP.NET 4.5 Data Sources The Future of Relational Databases Introducing Non-Relational Databases Data Access Services using ADO.NET Introducing Language-Integrated Query (LINQ) ADO.NET Entity Data Model and Entity SQL Designing Data Access Applications using Entity Framework Entity Framework Data Access Paradigms Consuming Data using WCF Data Services Data Binding in ASP.NET 4.5 Building Extensible Data-Driven Web Applications Using Dynamic Data Techniques to Deal with Issues in Building Data-Driven Web Sites Application Lifecycle Management
Chapters (12)
The last decade has witnessed an extraordinary evolution in the way that computing devices have affected our lives. They are far more pervasive and context driven than we could have ever imagined. The World Wide Web has been transformed from being a humble collection of linked pages to one displaying dynamic behavior based on context and user actions. Web sites today are capable of displaying responsive design, changing layouts based on the resolution of the target device, delivering content based on the location of the user, showcasing media without having the user download and install any media-specific plug-in, and the list goes on. The next decade will be the one where an immersive and fluidic experience for the client will drive innovation.
In Chapter 1, you learned that modern data-driven web sites built using ASP.NET 4.5 are capable of consuming data from a variety of sources. That being said, relational databases are leading in terms of their use in the enterprise and are the most widely used source of data for dynamic web sites. Relational databases make most sense in web applications that act as an interface for transactions waiting to happen within or outside the enterprise. The transactions could be between users or between users and systems. For web sites that are more like content-driven blogs, forums, and social sites, another category of databases is gaining prominence over relational databases. They are popularly known as NoSQL databases, and they are discussed in detail in Chapter 3.
ADO.NET and its predecessor ADO have a long history of facilitating direct data access for a variety of applications built using Microsoft technologies. ADO.NET has evolved tremendously since it was first introduced almost a decade ago. The biggest change in ADO.NET, however, was the addition of Entity Framework. The ability to work with a conceptual model against the native providers has captured the imagination of developers who want to use the .NET Framework for application development. Interacting with the conceptual model provided the abstraction level that programmers always wanted in their applications. In addition, this also reduced the number of lines of code that programmers had to write to fetch data from different sources, which made the technology extremely popular.
Emerging from a research project at Microsoft codenamed Comega (pronounced “see omega”), Language-Integrated Query, or LINQ as it’s now known, has been an integral part of the .NET Framework since version 3.5. Nothing else has advanced the evolution ADO.NET better than LINQ.
Entity Relationship Diagrams (ERD) are very popular for modeling data tiers. They allow architects and developers to create a conceptual model that is totally decoupled from the actual storage schema of any specific database. For data-driven applications, it is challenging, however, to map the conceptual model to a physical database since data is stored and retrieved from a variety of sources containing a mix of relational and object-based stores.
In Chapter 1, you were first introduced to the different data access paradigms. You also explored the steps required to create a data access layer easily from an existing database using the Entity Framework Entity Data Model (EDM) Designer and the Database-First paradigm. In addition, you learned how the EDM and ADO.NET Metadata System together form the core of Entity Framework in the previous chapter.
In Chapter 1, you were introduced to modern data access paradigms. To help you remember these, there are three primary strategies for designing a data access layer in your application.
Technologists invested their time trying to expose data as service over nearly the entire past decade. In doing so, the focus was inadvertently shifted from “data” to application logic. There are numerous reasons for this. While the need was for enterprises to distribute data to their partners and to consumers, there were concerns centering on security and transactions that led the shift in focus to Remote Procedure Calls (RPC)-style operations. The RPC style provided the much-needed abstraction for accessing and manipulating data, but it wasn’t intuitive for consumers. As a result, metadata had to be provided to consumers to help them understand the operations they could perform.
The chapters you have explored so far in this book have been focused on data access. You learned how easily you can create a data access layer using Entity Framework. You also learned about the different data access paradigms and how data access technologies are becoming standardized by means of protocols like OData for universal distribution.
To be honest, many front-end developers in the world of .NET hate it when it comes to writing queries against a database and figuring out if the data is consistent with the state of the application. They are more content working within the limits of Visual Studio and would line up to get their hands on a tool that would let them access relational data without having to write SQL queries. They are also pretty happy operating on data in memory using their language of choice, be it C#, VB, or LINQ, but not SQL. This is primarily due to the fact that each native relational database has its own flavor of SQL, and it is simply overwhelming to try and learn each one of them.
In reaching this point, you have gained a firm understanding of building modern data-driven Web applications using some of the key new features in .NET Framework. Since its 2.0 avatar, continuous enhancements in .NET Framework have been driven by extracting many of the heavy lifting operations you perform fetching and manipulating data through Web applications. The idea behind these enhancements was to help you focus on core business functionalities. In parallel, the developer community has invested significant time trying to create best practices from what they learned by using these new features in real-world scenarios.
Every enterprise-scale software program goes through a life cycle of planning, development, testing, and deployment in iterations, allowing customers to see what is being developed along the way and to provide feedback that effectively drives the quality of the software to their satisfaction. As a developer, you don’t just write code—you do many things in addition to writing code that align software development business needs. This is collectively called Application Lifecycle Management (ALM), and it includes the following tasks:
1.
Participating in product planning.
2.
Analyzing requirements to understand the conditions of customer satisfaction and breaking them down into deliverable tasks with specific estimates.
3.
Architecting the software in different layers and modules that interact with each other.
4.
Setting up environments for source control, build, and deployment.
5.
Managing source code to ensure that correct versions are released according to the plan.
6.
Writing unit tests to ensure that your portion of the work exhibits the desired behavior.
7.
Analyzing code for best practices on performance and maintenance through Code Analysis, performance counters, and code reviews.
8.
Building and deploying versions of the software for testing and feedback.
9.
Instrumenting code to trace issues and to debug the code.
10.
Communicating status and demonstrating progress.
ResearchGate has not been able to resolve any references for this publication.