LINQ to XML is an in-memory XML programming interface that enables XML manipulation. Similar to the more traditional Document Object Model (DOM), LINQ to XML brings XML documents into memory and lets you query and modify them before saving the results to a file or data stream. What is different from the DOM is the new, lighter, and more intuitive object model and LINQ integration.
When we think about querying databases, the first thing that pops to mind is usually some SQL query. Then other questions arise in regards to the database type, connection, query design, etc.
LINQ to Entities combined with Entity Framework allows the developers to skip a big portion of these questions and worries.
Entity Framework handles the database structure and connection while LINQ to Entities gives the possibility to write database queries in the same way as for any other data collection operation with LINQ.
Entity Framework is an open-source object-relational mapping (ORM) framework for .NET applications. It let the developers work with data on a higher level of abstraction without the need to worry about the database type or structure where the data is stored.
The focus of this article will be to show and explain how easy it is to add an Entity Framework to a .NET project.
The current article continues the series about LINQ. The previous part introduced the LINQ technologies and demonstrated its usage on some basic examples and a couple of more advanced coding challenges. The current article will further expose different ways to write LINQ query operations.
LINQ queries can be written in two syntax types, a Query Syntax and a Method Syntax.
Less is more – this is definitely true when it comes to object collections and LINQ queries.
Among the Language Integrated Query technologies, LINQ-to-objects is the most versatile. That’s why it will be the focus of this article. We will examine and compare traditional solutions to some programming challenges based on the data collections with alternative LINQ-based solutions.
Read MoreFor some reason, we often do not use this functionality. Maybe we haven’t got used to it yet. And sometimes we use it, having no idea that this is the functionality from F#.
Before reviewing it, let’s quickly run through the most interesting features that appeared in different versions of the language. Note that each time a new version of the language comes out with a new version of Visual Studio. For someone, this may be obvious, but even for developers who have worked with C# for several years, this may turn out to be a piece of news (not everyone takes notice of it).
I would like to start with a description of the problem that I encountered. There are entities in the database that need to be displayed as tables on the UI. The Entity Framework is used to access the database. There are filters for these table columns.
It is necessary to write a code to filter entities by parameters.
For example, there are two entities: User and Product.
public class User
{
public int Id { get; set; }
public string Name { get; set; }
}
public class Product
{
public int Id { get; set; }
public string Name { get; set; }
}
A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection. Client objects construct query specifications declaratively and submit them to Repository for satisfaction.
Entity Framework provides us with the actual implementation of the Repository patterns: DbSet<T> and UnitOfWork: DbContext. I often see colleagues using in projects their own implementation of repositories on top of the ones existing in Entity Framework.
Sooner or later, each developer has to create data tables with the possibility to sort by columns. I am not an exception. In our project, there are similar tables almost on every page. So, 90 % of the content is output on them. Of course, search and sorting by tables work without reloading a page.
As a rule, impersonal information is stored in a public cloud, and the personalized part – in a private cloud. The question thus arises – how to combine both parts to return a single result at a user’s request? Suppose there is a table of customers divided vertically. The depersonalized columns were included in the table located in Windows Azure SQL Database, and columns with sensitive information (e.g., full name) remained in the local SQL Server. Both tables must be linked by the CustomerID key. Because they are located in different databases on different servers, the JOIN statement will not work. As a possible solution, we have considered the scenario, when the linkage was implemented on the local SQL Server. It served as a kind of entry point for the applications, and the cloud-based SQL Server was set up on it as a linked server. In this article, we will consider the case when both, the local and cloud servers, are equal in terms of the application, and the data merging occurs directly in it, i.e. at the business logic level.