Navigation

RSS: Matt Pavey RSS Feed

Tuesday, June 8, 2010 @ 5:28 pm,LINQ,Matt Pavey

Dim x As IEnumerable(Of Integer) = From o In Orders From d In o.Details Select d.ProductID Distinct

Tuesday, May 6, 2008 @ 10:46 am,LINQ,Matt Pavey

I came across an article this morning that helped me with a LINQ query issue that I was trying to work through regarding dynamic queries.
 
 
My situation was very similar; however, in my case I was querying an ENTITY rather than SQL directly; however, the same rules applied.
 
I knew I could easily write a query that was not type safe and not checked at compile time; however, the thought of doing that really bothered me because I wanted to leverage the full power of LINQ and keep everything type safe and checked at compile time.
 
I ended up taking advantage of Lambda Expressions:

Public Function Search(ByVal Name As String, ByVal City As String) As IEnumerable(Of MyTable)
     Dim MyEntities As New DbEntities()
     Dim MyQuery As ObjectQuery(Of MyTable) = MyEntities.MyTableSet
     Dim MyResults = From x In MyQuery Select x

     If Not IsBlank(Name) Then
          MyResults = MyResults.Where(Function(e) e.Name.Equals(Name))
     End If
 
     If Not IsBlank(City) Then
          MyResults = MyResults.Where(Function(e) e.City.Equals(City))
     End If

     Return MyResults.AsEnumerable
End Function
 
More information on Lambda Expressions can be found here:
 

Tuesday, May 6, 2008 @ 10:29 am,LINQ,Matt Pavey

I started working on a new application for a client this week that is going to use the ADO.NET Entity Framework. Since it is not final release yet I had to download and setup the ADO.NET Entity Framework Beta 3. It wasn't too bad to get installed but I did run into a few issues along the way that I thought I'd share to save you some time if you end up having to do something similar.
 
I ended up having to install the following in this order:
 
ADO.NET Entity Framework Beta 3
 
ADO.NET Entity Framework Tools Preview can only be installed if a necessary Visual Studio patch is installed.
 
ADO.Net Entity Framework Tools Dec 07 Community Technology Preview
 
At this point I had everything installed so I could add a ADO.NET Entity Data Model to my project.
 
Another good resource for ADO.NET related info can be found here:
 
 
One other thing I did notice when working with the ADO.NET Entity Data Model was that it all seemed to be very straight forward to setup and test if your UI and data access were in the same project; however, I found that when setting up a n-tier architecture I ran into some annoyances. The data layer I setup contained my ADO.NET Entity Data Model and it automatically creates an App.Config file with the necessary connection information and it creates the .csdl file, .ssdl file and .msl file in the data layer's /bin folder; however, when you add a reference to your data layer from your UI or business layer it does not automatically copy the connection string information into your Web.config file and it does not copy the .csdl file, .ssdl file and .msl file into the web application's /bin folder. So I ran into error messages until I finally figured out was going on.
 
To work arond this I created a Config/ConnectionStrings.config file and copied the connection information from the App.Config file into the new config file and had the Web.config reference the new config file. Then I copied the .csdl file, .ssdl file and .msl file into the web application's /bin folder. Once I did this I was able to use the ADO.NET Entity Data Model as my data access and isolate the data access to the data layer. The issue with this is that if you change your model you have to manually copy the files to the web application's /bin folder again. I'm hoping that I'm either just not doing something right or this is just because it is still Beta and will be easier in the final release.
 
I also found that quite a few code samples I came across had the Using ... End Using notation around their entity code; however anytime I returned a generic list, for example IEnumerable(Of T), from the data layer to another layer the connection would be lost and I would get an error that said:
 
A connection string must be set on the connection before attempting the operation.
 
It wasn't apparent to me what the problem was initially but then I took out the Using ... End Using notation and everything worked perfect. The End Using code from the code samples was forcing certain objects to be destroyed, including the connection.
 
I've tested retrieving data, adding data, deleting data, updating data, filtering data using standard LINQ syntax as well as Lambda Expressions and binding IEnumerable(Of T) data to a GridView.
 
So aside from the minor annoyances I ran into along the way I now have a working project that uses the ADO.NET Entity Data Model.

Sunday, March 2, 2008 @ 11:48 am,LINQ,Matt Pavey

Here's an interesting article regarding the challenges of creating a true data access layer using LINQ to SQL.
 
 
It's an older article; however, it covers some interesting questions. I'd recommend in addition to reading the article actually reading through the responses as well at the end of the article.
 
"... it is absolutely not clear where a developer should draw the line between what’s business logic, and what belongs in the DAL ..."
 
It seems the primary concerns are what exactly the data access layer should be returning and where exactly the actual query should be executed.
 
"That is, the data access layer should be returning just arrays of entities (T[] or IEnumerable). It should [not] be returning IQueryable. Returning IQueryable gives you more rope to hang yourself with because (i) the caller (business logic layer) can redefine the query that ultimately gets sent to the database (ii) the caller (business logic layer) now executes the query because of deferred query execution (iii) the distinction between the caller (business logic layer) and the DAL blurs."
 
If you return IQueryable(Of T) objects from the data access layer the queries are not actually getting 'executed' until you use them later, for example when you enumerate over the IQueryable(Of T) data in your business or UI. So by returning List(Of T), IEnumerable(Of T) or an Array of entities you draw a fine line with what the data access layer handles vs. what the business layer or UI handles.
 
I've played around with returning IQueryable(Of T), List(Of T), IEnumerable(Of T) and an Array of entities. Each has their own advantages or caveats. My research so far leads me to believe that IEnumerable(Of T) is the preferred approach.
 
"The main design pattern that arises from LINQ is to prefer IEnumerable(Of T). This is because LINQ operates on IEnumerable(Of T), and if you design your application around IEnumerable(Of T), you will find many places where a LINQ query will provide an elegant solution to your problem."
 
Here's a couple articles that discuss IEnumerable(Of T) in more detail:
 
 
 
It will be interesting to see how each developer decides to implement LINQ into their projects and how consistent it will be with what others are doing.
 
"I hate it when developers have to make choices like that during routine development. Choosing takes time, and that’s not likely to improve productivity. But much worse is the fact that different developers will make different choices. Even a single developer may make different choices from one day to the next. That leads to inconsistencies in the code. Developers will spend more time trying to understand the code they’re reading, because it doesn’t always follow the same pattern. That’s bad for productivity. In the worst case scenario, developers start rewriting each other’s code, just so it matches their choice of the day. That kills productivity."
 
I think having a nice set of standards before fully integrating LINQ into a project is going to be a smart move, especially in team environments.

Tuesday, February 26, 2008 @ 4:32 pm,LINQ,Matt Pavey

"LINQ to XML is a built-in LINQ data provider that is implemented within the "System.Xml.Linq" namespace in .NET 3.5."

"LINQ to XML provides a clean programming model that enables you to read, construct and write XML data.  You can use LINQ to XML to perform LINQ queries over XML that you retrieve from the file-system, from a remote HTTP URL or web-service, or from any in-memory XML content."

"LINQ to XML provides much richer (and easier) querying and data shaping support than the low-level XmlReader/XmlWriter API in .NET today.  It also ends up being much more efficient (and uses much less memory) than the DOM API that XmlDocument provides."

http://weblogs.asp.net/scottgu/archive/2007/08/07/using-linq-to-xml-and-how-to-build-a-custom-rss-feed-reader-with-it.aspx

Tuesday, February 26, 2008 @ 4:25 pm,LINQ,Matt Pavey

"One of the nice development features that LINQ to SQL supports is the ability to use a "debug visualizer" to hover over a LINQ expression while in the VS 2008 debugger and inspect the raw SQL that the ORM will ultimately execute at runtime when evaluating the LINQ query expression."

 

Tuesday, February 26, 2008 @ 1:37 pm,LINQ,Matt Pavey

"Developers can use LINQ with any data source.  They can express efficient query behavior in their programming language of choice, optionally transform/shape data query results into whatever format they want, and then easily manipulate the results.  LINQ-enabled languages can provide full type-safety and compile-time checking of query expressions, and development tools can provide full intellisense, debugging, and rich refactoring support when writing LINQ code."
 
"LINQ to SQL is an O/RM (object relational mapping) implementation that ships in the .NET Framework "Orcas" release, and which allows you to model a relational database using .NET classes.  You can then query the database using LINQ, as well as update/insert/delete data from it."

"LINQ to SQL fully supports transactions, views, and stored procedures.  It also provides an easy way to integrate data validation and business logic rules into your data model."


Tuesday, February 26, 2008 @ 1:27 pm,LINQ,Matt Pavey

"When one takes a look at the amount of code that the average application developer must write to address the impedance mismatch across various data representations (for example objects and relational stores) it is clear that there is an opportunity for improvement. Indeed, there are many scenarios where the right framework can empower an application developer to focus on the needs of the application as opposed to the complexities of bridging disparate data representations."

"A primary goal of the upcoming version of ADO.NET is to raise the level of abstraction for data programming, thus helping to eliminate the impedance mismatch between data models and between languages that application developers would otherwise have to deal with. Two innovations that make this move possible are Language-Integrated Query and the ADO.NET Entity Framework. The Entity Framework exists as a new part of the ADO.NET family of technologies. ADO.NET will LINQ-enable many data access components: LINQ to SQL, LINQ to DataSet and LINQ to Entities."

"This document describes the ADO.NET Entity Framework, what problem spaces it is targeting and how its various components address those problems."

http://msdn2.microsoft.com/en-us/library/aa697427(VS.80).aspx

Wednesday, January 23, 2008 @ 4:20 pm,LINQ,Matt Pavey

Visual Basic
 
C#

Wednesday, January 23, 2008 @ 12:43 am,LINQ,Matt Pavey

The LINQ (.NET Language Integrated Query) Project is an initiative to standardize data access across data sources and development.
  
This is an interesting article by Arthur Fuller that explains why he's not convinced that LINQ will revolutionize database application development.
 
 
I can't say I completely agree or disagree with all of the comments he makes in the article; nonetheless, I found it an interesting read. Be sure to read the "comments on this article" to see how certain people have reacted to both sides of the argument.
 
Like Arthur Fuller I've always been a strong proponent of Whatever the back end can do, the back end should do. This certainly has to be looked at on a project by project basis, but typically the projects I'm involved in and architect have benefited from a separate data layer with stored procedures for data access. So naturally I had skepticism as I began reading, researching, and testing LINQ.
 
With that said - I don't necessarily look at LINQ as having to move all back end code to the front end. I think it ends up being strictly up to how the solution is architected and how the developer wants to utilize it. Unfortunately, with LINQ in its infancy almost every code-snippet, documentation or article has some misleading examples that make it appear that all the data access code must now be moved to the front end of an application. I have to admit with my first several examples it was simple enough for me to drop a DBML file in the web project and write some quick code to test it. But of course after I saw it worked I immediately created a "Data" layer and moved the DBML file there and continued testing. That way the data access layer did just that, access data, and the front end could use the data accordingly.
 
This comment seemed to sum up exactly what I was thinking as I waded through all the pros and cons of how LINQ will affect the future of database development:
 
LINQ is a tier neutral technology. On the front end one can use LINQ to query returned datasets, XML files etc and on the back end to query a database. IMHO the back end (data access tier - DAC) is the only tier that is allowed to access data storage like SQL Server. The front end can manipulate returned data from the back end but not retrieve or update it without using the DAC. LINQ is merely a uniform way of accessing different data sources. New functionality like LINQ does not force bad coding style, that is left up to the creativity of the developer.
 
So although no conclusive agreement has been reached in the development community regarding the future of LINQ, I am optimistic and look forward to learning more about it over the next several weeks and months...

Tuesday, January 22, 2008 @ 9:54 pm,LINQ,Matt Pavey

If you tested BETA releases of Visual Studio 2008 and the .Net 3.5 Framework you'll find that some minor changes were made for the final release.
 
In particular one issue I ran into this evening was testing and writing sample code that I found in the MSDN documentation that used the Add and Remove methods of the System.Data.Linq.Table class.
 
The Add method was changed to InsertOnSubmit and the Remove method was changed to DeleteOnSubmit.
 
While more wordy, the change was made to make them more explicitly describe their behavior.

Tuesday, January 22, 2008 @ 12:10 am,LINQ,Matt Pavey

I started using Visual Studio 2008 today. So far I haven't ran into any problems. In fact, I've tried it on Vista and XP and both installations went very smooth.
 
I've tested a few different scenarios, inluding working with one of my Visual Studio 2005 .Net 2.0 applications without upgrading to .Net 3.5. I didn't have any noticeable problems in doing so and was able to work with the application as it were 2.0 as expected. And I had all the benefits of Visual Studio 2008. The intellisense for JavaScript was very slick. I don't typically have to write a ton of JavaScript code, but the fact that it's going to be easier to work with and debug is a very nice feature.
 
I also tested converting an existing 2.0 application to 3.5. Again, I saw no noticeable problems. And once converted to 3.5 I had all the additional benefits of the 3.5 framework at my disposable.
 
And lastly I created a .Net 3.5 web application from scratch and had no problems. I did some very basic testing initially, and even got involved in writing my first lines of LINQ code. Quite remarkable!
 
Here's a great link for Visual Studio 2008 samples that was helpful for me to get started, particularly with LINQ.
 
 
The "Hands On Labs" are perfect if you are just getting started with the LINQ syntax and LINQ to SQL syntax. The documents are available for VB and C#.
 
In a matter of minutes I had a connection to a database and fully generated classes by dragging and dropping tables to my "LINQ to SQL Classes" file.
 
The only code I had to write was to query the data using LINQ and do some basic operations on it.
 
Definitely looking forward to getting more involved with Visual Studio 2008 and LINQ!

The opinions expressed on this website are my personal opinions
and do not represent my employer's or my clients' views in any way.