LinQ To Sql Provider -- do we have to create our own?

[Rich P]

AdventureWorksDataContext dataContext =
new AdventureWorksDataContext();

var query = from contact in dataContext.Contacts
where contact.EmailPromotion==1
select contact;
<

I should probably ask this first:

-->> AdventureWorksDataContext

is this the LinQ To Sql provider? If no -- then where does
AdventureWorksDataContext come from? If yes, do we have to create our
own (for like another data source)? I found an article on msdn

Walkthrough: Creating an IQueryable LINQ Provider

at http://msdn.microsoft.com/en-us/library/bb546158.aspx

This seemed fairly involved. If this is the way it is done for LinQ To
Sql then I am missing the improved value of this over someting like:

SqlConnection conn = new SqlConnection...
SqlDataAdapter da = new SqlDataAdapter...

da.SelectCommand.CommandText = "Select * From Contacts..."

The only thing I could see is that you would have the ability to debug
the Select Statement with the LinQ approach. Am I putting the pieces
together correctly here?



Rich

 

[Alberto Poblacion]

I should probably ask this first:

-->> AdventureWorksDataContext

is this the LinQ To Sql provider?

No, if working with SQL Server you would use the classes in
System.Data.Linq for the Sql Provider.

If no -- then where does
AdventureWorksDataContext come from?

AdventureWorksDataContext is a class that inherits from DataContext, much
in the same way as a typed DataSet is just an autogenerated class which
inherits from DataSet.
You *can* use linq-to-Sql directly by means of the DataContext class, but
then you would need to define your entity classes manually and invoke them
by means of generics. This work is simplified by Visual Studio: When you add
a "linq to sql classes" (.dbml) file to your project, Visual Studio provides
you with a designer where you can drag and drop tables from the server.
Visual Studio then writes a source code file that defines the entity
classes, along with a class that inherits from DataContext (such as the
"AdventureWorksDataContext" class that you mentioned.

 

[Andy O'Neill]

Walkthrough: Creating an IQueryable LINQ Provider

at http://msdn.microsoft.com/en-us/library/bb546158.aspx

This seemed fairly involved. If this is the way it is done for LinQ To
Sql then I am missing the improved value of this over someting like:

SqlConnection conn = new SqlConnection...
SqlDataAdapter da = new SqlDataAdapter...

da.SelectCommand.CommandText = "Select * From Contacts..."

The only thing I could see is that you would have the ability to debug
the Select Statement with the LinQ approach. Am I putting the pieces
together correctly here?

I think you're looking at some of the pieces of the puzzle and missing the
big picture.

Creating your data model thingummy is drag and drop.
Give it a twirl.
It ain't hard.

Once you create your sqldataadapter and fill it, what next?
Because if your answer involves strongly typed datasets then that's an
overhead ain't going to fly for an asp.net application.
Not even a possibility for a silverlight app.
With them you'd want some sort of intermediate object and probably a typed
list/ienumerable/observable collection/whatever.
LinqtoSQL just generated your type with that drag and drop.

Let's have a quick squint at linked tables.
Now I can write them joins in my sleep now, maybe you can too.
But you don't need to even think about how they're joined ( well. most of
the time anyhow ).
Drag them tables, the relationships are modelled.
Wham bam the child of parent table is a collection inside your parent type.

Not impressed?
Neither was I initially.
Linq?
I thought.
I'm a T-SQL expert.
I don't need no steeeenkin leeeenk.
(film reference).

Then I did some extension methods on my model classes.
I thought - hmmm that was kind of cool.

Then I had to work with some xml and I did some linq to xml.
I thought - well that wasn't so hard.

Then I came across a pattern.
Pipeline and filter.
This was my particular road to damascus moment.
Google it.
The linq isn't translated to SQL and thrown at the database until you
iterate the list.
So you can keep on nailing on extra where's and whatnot in a way that would
be a nightmare building sql.
User configurable search and sort, no problemo.

So like I said.
Big picture mate.

Of course if you really want to just chuck a strongly typed dataset at a
windows form then you can still do that.
Still works.
Just hope you don't need business logic or validation.

 

[Rich P]

Hi all,

Thank you for your replies, and sorry for my ignonuramus_ism on the
subject of LinQ to Sql (LinQ in general). This does clear up a few
things, which is why I asked. And yes, I just noticed the "LinQ To Sql
Classes" template in VS(2008). I will chew on this for a while. I am
sure I will be back.

Rich

 

[Rich P]

OK. That wasn't so bad. Here is what I did (documenting for my own
posterity and for suggestions).

I selected a dbml template from the Add Item menu (VS2008) and named it
AdventureWorks (I copied a code sample from an earlier post on this
topic). Then I clicked OK. It took a while for the thing (dbml window
-- whatever it is called) to come up in Studio. I noticed that VS
tacked on DataContext to the AdventureWorks name that I gave it.

Then I dragged the Contacts table from Server Explorer (AdventureWorks
DB) and plopped it into the left pane of the dbml window. Saved
everything.

Next I added a form to my project with a button and a datagridview
control and then added this code to the button:

private void button2_Click(object sender, EventArgs e)
{
AdventureWorksDDataContext dataContext = new
AdventureWorksDataContext();
var query = from contact in dataContext.Contacts
where contact.EmailPromotion == 1
select contact;

dgrv1.DataSource = query;
}

I clicked the button, and the datagridview got populated immediately.
No problems.

Question: the right pane of the dbml window says you can create methods
by dragging items from the server explorer. I tried dragging another
table into this pane but it wouldn't let me. Where do I get something
to drag into this pane? What do I drag into this pane?



Rich

 

[Andy O'Neill]

Question: the right pane of the dbml window says you can create methods
by dragging items from the server explorer. I tried dragging another
table into this pane but it wouldn't let me. Where do I get something
to drag into this pane? What do I drag into this pane?

Methods do things to stuff.
Tables store stuff.
So you need something in a database that does stuff rather than stores
stuff.

 

[Rich P]

of course. Thanks. UDFs, SPs.

Rich

 

[Mr. Arnold]

AdventureWorksDataContext dataContext =
new AdventureWorksDataContext();

var query = from contact in dataContext.Contacts
where contact.EmailPromotion==1
select contact;
<

I should probably ask this first:

-->> AdventureWorksDataContext

is this the LinQ To Sql provider? If no -- then where does
AdventureWorksDataContext come from? If yes, do we have to create our
own (for like another data source)? I found an article on msdn

It's not a Linq provider. The Context in this case is in the designer.cs
that was generated when you told Linq-2-SQL to generate the model. It
points the the SQL server connection sting and also where the view of
the Linq-2-SQL model is located.

It could have been NorthwindDataContext indicating that the Link-2-SQL
generated designer.cs was pointing to table views of the Northwind database.

In order for you to open the AVWDB the very first line in the code above
it was opened using the Context that pointed to the AVWDB in code in the
designer.cs.

A Linq provider is in the list of Linq providers.

http://rshelton.com/archive/2008/07/11/list-of-linq-providers.aspx

A Linq provider is basically anything that will allow one to query a
collection, table, dataset, DB, XML etc, etc by usage of Linq.

Walkthrough: Creating an IQueryable LINQ Provider

at http://msdn.microsoft.com/en-us/library/bb546158.aspx

Yes, the information in the link above is a Linq provider. It's a Linq
provider that allows a Web client to use Linq to query its Web site
through the means of using Linq-2-SQL, ADO.NET Entity Framework
nHibernate and many other ORM solutions on the back-end.

What the link is showing you is what is needed to set-up your own Web
site to be a Linq provider so that a client can query data linked to a
back-end database with Linq. That's what the link is showing you.

This seemed fairly involved. If this is the way it is done for LinQ To
Sql then I am missing the improved value of this over someting like:

Yes, it fairly involved to set-up a Web site as a Linq service provider

SqlConnection conn = new SqlConnection...
SqlDataAdapter da = new SqlDataAdapter...

da.SelectCommand.CommandText = "Select * From Contacts..."

Linq-2-SQL does it for you. It makes the Select statement for you, makes
the connection to SQL server and returns a result of Contacts.cs objects
for you to work with -- no muss no fuss by this one Linq-2-SQL query
statement.

var query = (from contact in dataContext.Contacts
where contact.EmailPromotion==1
select contact).ToList();

That would have brought back a List<Contact> for you.

or .FirstOrDeFault world have brought back a single instance of Contact

or dataContext.Contacts.Include("Address") if Address is a child of
Contact. The T-SQL statement would be generated behind the scene an d
executed for you.

The only thing I could see is that you would have the ability to debug
the Select Statement with the LinQ approach. Am I putting the pieces
together correctly here?

No, you're nowhere in the ballpark with your understanding of Linq.
Linq-2-SQL which is a Linq provider is just one aspect of using Linq.
Linq is a separate .NET solution into itself that allows one to use
expressions to query some type of data stor.

What is Linq?

http://en.wikipedia.org/wiki/Language_Integrated_Query

 

[Rich P]

Re: LinQ To Sql Provider -- do we have to create our own?
From: Mr. Arnold
...

What is Linq?

http://en.wikipedia.org/wiki/Language_Integrated_Query
<

Thanks. Your post was quite informative. I will follow the links to
LinQ.

Rich