Hello again Ronnie,
     This is actually of Marco's original design and not something related to LINQ! If you open up ShowArticle.aspx.cs and jump down to ~ line 45 you will see this code:
I assume that you are passing in bogus Article ID's to see how the application will respond?

Thanks.

-Doug

================================================== =========
Read this if you want to know how to get a correct reply for your question:
http://www.catb.org/~esr/faqs/smart-questions.html
================================================== =========
.: Wrox Technical Editor / Author :.
Wrox Books 24 x 7
================================================== =========

Hi Doug,

No, I'm passing actual ID's, with no change to the tbh_Articles, I'm accessing any one of the ShowArticle.aspx links from BrowseArticle.aspx which works with either Marco's SiteProvider or your actual example you used for this method using the IQueryable<T> interface.

The goal is to play with variations and use the queries you used for the GetArticle() with the SPROC, or the direct LINQ query that was used for the UpateArticle().

I followed the rules about using IQueryable<T> and it requiring indexing and conversion ToList. And when using the strictly LINQ way, removed it and used the .First(), but I'm thinking I did something incorrectly or missing something.

Thanks,
Ronnie

I'm just starting to work through this Blox, and have already noted a couple of errors which I don't believe have yet been documented. There may be more, but I wanted to post these before I forget:

Page 6:

Select these three tables:

• tbh_Category
• tbh_Article
• tbh_Comment

These are the names of the context objects, not of the actual tables you need to select. So, this should read:

Select these three tables:

• tbh_Categories
• tbh_Articles
• tbh_Comments

Also, on page 13:

where x.LanguageName = "CSharp"

should be

where x.LanguageName == "CSharp"

Another error:

On page 11:

tbh_Articles_GetArticleByID should be added to the list of stored procedures to drag into the Methods Pane.

If you read a bit on you'll see it's the other way around. tbh_Articles_GetArticleByID should not be listed. The example for the method ends up using the "Dynamic query" using IQueryable<tbh_Article> instead of the SPROC.

Yet my recommendation is to mix and match different queries (further in the Blox) in the various methods to get a feel for LINQ.

Then, in that case, it should not be listed on page 20, under where it says: "To speed the conversion up, switch over to your O/R Designer and set up the return type of the following stored procedures to tbh_Article:".

guys,

after working thro' this topic on and off for the past month, I have to say that as of the current moment, i'm not persuaded by the argument to add LINQ functionality to TBH, other than as an academic excercise. i feel that linq to entities will be the next evolution that will make significant differences to the framework and really will open up new possibilities insofar as how we interact with data.

i'd be interested to hear how you guys have coped with/elaborated on doug's original article (which was a nice little primer to be honest) and added measureable value against the 'vanilla' implementation of the straight SQLClient approach. i was looking thro' some linq stuff the other day and stumbled upon this little article:

http://freekleemhuis.wordpress.com/2...-stuff-part-1/

the paragraph:

Since we had the lauch of Visual Studio 2008 last week, Linq to SQL is now widely available. Linq to SQL is a light-weight OR-Mapper. Is this the best framework for persisting your data? No, by no means. If you are currently using a feature-rich OR-Mapper like NHibernate or LLBLGen, you wouldn’t want to switch to Linq to SQL. However, if you’re new to the practice of OR mapping, Linq to SQl can be a good choice to get you started.

caught my attention in particular and perhaps illuminated for me the fact that chasing the edge can obscure the existing landscape.

all the best for now....

jimi

http://www.originaltalent.com

Don't forget... LINQ is not just about relational data. There is LINQ to Objects, LINQ to XML, and LINQ to DataSets out of the box, and with the provider model, pretty soon there will be LINQ to everything else. I really believe that LINQ is the future. Microsoft has certainly made it clear they intend to go in that direction.

By the way, the Entity Framework won't require LINQ to work with it, as they will also be providing an Entity SQL framework that will work a lot like ADO.NET.


As I pointed out in another post, I have some quibbles with the way Doug approached some of the specific functionality, and I intend to post some details on that soon. That being said, the main advantages, as he points out, are compile-time checking, not having to mess with plumbing code, a much simpler DAL, and automatic query optimization (with the potential to optimize queries even further with future compiler/SQL Server releases).

Keep in mind, there are a lot of other advantages that he doesn't utilize here, like L2SQL's built-in efficient server-side paging (he retains the original paging scheme), built-in concurrency control (not implemented here), partial methods for custom business logic, and object inheritance in the DAL. There is a lot more that could be done to leverage the full power of LINQ to SQL in TheBeerHouse, although I understand that the author has a rather limited number of pages to work with, and he did a good job in as far as he took it.

While I agree that LINQ to SQL is not as powerful as some of the more feature-rich mappers out there, we're just seeing the tip of the iceberg right now. With the Entity Framework and MVC, I predict that stuff like NHibernate and LLBLGen will suffer the same fate as that of the early third party AJAX frameworks after MS AJAX came out -- basically relegated to obscurity.

lee - you might want to check this out (if you haven't already!!) as it uses linq with a thin dal supplying the bll layer:

http://dotnetslackers.com/articles/a...fBlogoNET.aspx

it's actually quite a decent implementation and one that could easily be ported over to TBH architecture whilst maintaining the linq functionality. anyway, hopefully should give a few ideas.

jimi

http://www.originaltalent.com

This should also be corrected:

In the section "Conversion of the Category and Comment Classes" starting on page 26, it should be pointed out that, to get the TBH-dbml methods to return the types that the code expects, you need to change the return type of the tbh_Articles_GetCategories method to tbh_Category (instead of Auto), and that the return types of tbh_Articles_GetComments and tbh_Articles_GetCommentsByArticle should be changed to tbh_Comment.

If this is not done, you will get casting errors from the failure of the compiler to cast the auto-generated types to tbh_Category or tbh_Comment as required.