Open Post to the C# Development Team

[Michael S]

Can you write DLINQ that works with both stored procedures and normal
tables without changing the DLINQ query?

In other words, if in my app I write something like:

var data = from s in SOMETHING where ...

can SOMETHING for one database server be a stored procedure, and for
another be a table, or will it be locked to one type or the other?

Hmm. Stored Procedures maps to methods on your DataContext, so it can't be
easily compared.
But for a more general answer, SOMETHING can be anything that implements
IEnumerable<T> like an Array or a List.

For more complex structures LINQ works if it has a provider for it, i.e that
has a custom implementation of IQuerable<T>. Take xml for instance, it can
be queried using LINQ by using System.Xml.Linq.

LINQ is so powerful, that you can even make join a database, a list and a
xml-document in one single query and also group them.

I ask because in some environments, data separation is done with tables
and sql in a data layer for one type of database, and stored procedures
for another.

Well this is a matter of taste.
You can always map all your stored procedures to a DataContext, but then you
are not really making much use of linq.

The whole point of separating data and code is that you can change the
implementation of one without affecting more than one layer up. In this
case it looks, but I could be wrong, like you've pulled details about the
database implementation directly up into the application.

Some people like the idea of keeping all sql in the database in form of
stored procedures.
One argument would be that you can make changes in your schema and not
affect applications.

In my experience this never happens. Typically it is always the application
that changes, that then demands changes in the database. Maybe for a
enterprisy system with many application sharing the same database, things
might be different.

I mostly work with one appliction, one database.
Consider the system I am working on now.
We got a 3 layer architecture on 2-tiers.

-- tier 1
ASP.NET web-site. - presentation
LINQ DAL .dll - business logic / rules
--- tier 2
SQL Server 2005 - data / schema

As by not using stored procedures we have really seperated data and code. =)

Personally I like this, if we also have the power to force one or the
other.

Well that would be easy, just don't use plinq. =)
But maybe the OP has a point. I think some low-level classes are missing in
..NET

It would be cool if .NET could sport a red-black-binary-tree, and why not a
balanced B-Tree.
Also, it would also be a good thing if there different sorting algorithms
already implemented instead of just '.Sort method uses quicksort'.

Well, there are always third party components.

- Michael Starberg

 

[Michael S]

In Delphi classes have a vtable as well, yes, and this is linked to what
you get back in the code above.

But you can do so much more. Static methods can be truly virtual in Delphi.

Let's say you have a method taking a pointer of object of TStream.
I call this method passing a pointer of object of THttpStream.

Now this method could instantiate the TStream, that is actually a
THttpStream.
Would the method then calla a overriden static method, the correct method
(i.e the one on THttpStream) would be called.
If the method is calls its base, it would be called correctly too.

Not often you need this feature, but from reading posts in this group, the
few people that do gets very very sad when they learn it is impossible to
do, or even fake, in C#.

- Michael Starberg

 

[Nicholas Paldino [.NET/C# MVP]]

Just curious, in regards to calling your SP's natively (which is not
what you mean really, you want a type-safe wrapper to call the SP, very
different), have you even looked at the data set designer? You should be
able to open up the server explorer (assuming your data provider supports
it) and then drag the stored procedure onto the data set designer, and it
will create a typed wrapper for you. This has been around at least since
VS.NET 2005 (I'm not sure about earlier) and it does support ODBC data
sources.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Re calling SPs more easily... how about just an exmaple?
Add a "LINQ to SQL classes" file, named kinda like your database; the
dbml designer should appear. I've opted for Northwind, so in the
Server Explorer I've locate the database, expanded "Stored Procedures"
and dragged "Ten Most Expensive Products" into the designer (righ hand
pane; left is data entities). You can tweak the (object-model) name if
you like (it replaces space with underscore by default). Note that it
will inspect the SP to see how it behaves, and try to model the args
and return value accordingly (you can fixup any oddities in the xml if
needed).

Each dbml creates an "data context" (which btw is extensible, both by
partial classes and the new partial methods); procs then appear as
instance methods on that dc (tables as queryable entities); for
instance:

using (NorthwindDataContext db = new
NorthwindDataContext()) {
foreach (var product in db.TenMostExpensiveProducts())
{
Console.WriteLine("{0}: {1}",
// this is the bizarre column name
// from the SP! Blame Northwind... could
// probably change in the dbml if needed
product.TenMostExpensiveProducts,
product.UnitPrice);
}
}

and it works:

Côte de Blaye: 263.5000
Thüringer Rostbratwurst: 123.7900
Mishi Kobe Niku: 97.0000
Sir Rodney's Marmalade: 81.0000
Carnarvon Tigers: 62.5000
Raclette Courdavault: 55.0000
Manjimup Dried Apples: 53.0000
Tarte au sucre: 49.3000
Ipoh Coffee: 46.0000
Rössle Sauerkraut: 45.6000

There is a *lot* more depth here, especially when talking about procs
that are CRUD for your entities (that should *also* be part of the
dbml). But the point is - we haven't had to had-crank any of the
command, args or result. It should work OK against most SQL Server
variants (SQL2000 is a bit limited, but 2005+ including express are
fine). And "LINQ-to-Entities" (Entity Framework) provides multi-vendor
support and significantly more complex mappings (I'm not sure if this
latter is a good thing or not).

But to my view: they *have* addressed the "why to I have to write all
this data access code"... it is the primary goal of LINQ-to-SQL.

Marc

Well done, sir. I wonder why it can't do any arbitrary ODBC source?
Seeing as I use MySQL for half my projects and SQL 2000 for another
quarter, that would be very convenient.

There is actually a book from Microsoft Press about generating code
with xslt's, including a full O/R layer. I'm left to wonder why they
didn't use this approach since it is data source neutral. Perhaps
simply a case of vendor lock-in.

 

[Michael S]

Just curious, in regards to calling your SP's natively (which is not
what you mean really, you want a type-safe wrapper to call the SP, very
different), have you even looked at the data set designer? You should be
able to open up the server explorer (assuming your data provider supports
it) and then drag the stored procedure onto the data set designer, and it
will create a typed wrapper for you. This has been around at least since
VS.NET 2005 (I'm not sure about earlier) and it does support ODBC data
sources.

Excellent proof of point.
Just because we get new technology,
doesn't mean the old ones are not still there =)

- Michael Starberg

 

[rossum]

Javascript (weekly typed language + lots of paradigms)

So that is why my Javascript works one day and fails by the next
Monday. "weekly typed". Hmmm.

rossum

 

[Michael Starberg]

So that is why my Javascript works one day and fails by the next
Monday. "weekly typed". Hmmm.

rossum

Hehe, and this is obviously why the OP compares C# with JavaScript.
They are sooo similar, as they both have the 'var' keyword. =)

I wonder if the troller knows the difference between type inference and
variants.

- Michael Starberg

 

[RobinS]

I seriously doubt the C# development team reads this forum. You might try
posting to the MSDN forum for C#, or (better yet) submitting your opinions
via the feedback website. Posting a letter to the C# development team here
is akin to posting a letter to Santa Claus.

RobinS.

 

[Michael Starberg]

I'm not sure I'd agree with that...

Well, now I am sure.

He posted his angry letter,
made a few comments that showed that
he don't even know .NET 3.5 nor C#3
and have then not responded at all.

I call that trolling.

But it is ok, becuase sorrounding his lame post,
we had a great discussion.

- Michael Starberg

 

[Michael Starberg]

I seriously doubt the C# development team reads this forum. You might try
posting to the MSDN forum for C#, or (better yet) submitting your opinions
via the feedback website. Posting a letter to the C# development team here
is akin to posting a letter to Santa Claus.

RobinS.

I am pretty sure the C# development team reads this forum.

But I also think they refrain from replying, as it is supposed to be a
community peer2peer forum.

However, the OP is just trolling...

- Michael Starberg