 |
BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0  | This is the forum to discuss the Wrox book ASP.NET 2.0 Website Programming: Problem - Design - Solution by Marco Bellinaso; ISBN: 9780764584640 |
|
Welcome to the p2p.wrox.com Forums.
You are currently viewing the BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0 section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
|
|
|
|

April 26th, 2008, 07:59 PM
|
Wrox Author
|
|
Join Date: Oct 2005
Posts: 4,104
Thanks: 1
Thanked 64 Times in 64 Posts
|
|
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:
Code:
Article article = Article.GetArticleByID(_articleID); <--LINQ is called from here
if (article == null)
throw new ApplicationException("No article was found for the specified ID."); <--This is the exception you are seeing
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
================================================== =========
|

April 26th, 2008, 10:57 PM
|
Authorized User
|
|
Join Date: Mar 2008
Posts: 62
Thanks: 1
Thanked 3 Times in 3 Posts
|
|
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
|

April 30th, 2008, 02:41 PM
|
 |
Wrox Author
|
|
Join Date: Jan 2008
Posts: 923
Thanks: 12
Thanked 166 Times in 162 Posts
|
|
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"
|

April 30th, 2008, 04:34 PM
|
 |
Wrox Author
|
|
Join Date: Jan 2008
Posts: 923
Thanks: 12
Thanked 166 Times in 162 Posts
|
|
Another error:
On page 11:
tbh_Articles_GetArticleByID should be added to the list of stored procedures to drag into the Methods Pane.
|

May 1st, 2008, 10:59 PM
|
Authorized User
|
|
Join Date: Mar 2008
Posts: 62
Thanks: 1
Thanked 3 Times in 3 Posts
|
|
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.
|

May 2nd, 2008, 09:39 AM
|
 |
Wrox Author
|
|
Join Date: Jan 2008
Posts: 923
Thanks: 12
Thanked 166 Times in 162 Posts
|
|
Quote:
quote:Originally posted by kalel_4444
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.
|
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:".
|

May 2nd, 2008, 10:11 AM
|
Friend of Wrox
|
|
Join Date: Mar 2007
Posts: 488
Thanks: 2
Thanked 11 Times in 10 Posts
|
|
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
|

May 2nd, 2008, 11:45 AM
|
 |
Wrox Author
|
|
Join Date: Jan 2008
Posts: 923
Thanks: 12
Thanked 166 Times in 162 Posts
|
|
Quote:
quote:Originally posted by jimibt
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.
|
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.
Quote:
quote:Originally posted by jimibt
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.
|
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.
Quote:
quote:Originally posted by jimibt
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.
|
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.
|

May 2nd, 2008, 03:10 PM
|
Friend of Wrox
|
|
Join Date: Mar 2007
Posts: 488
Thanks: 2
Thanked 11 Times in 10 Posts
|
|
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
|

May 5th, 2008, 03:21 PM
|
 |
Wrox Author
|
|
Join Date: Jan 2008
Posts: 923
Thanks: 12
Thanked 166 Times in 162 Posts
|
|
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.
|
|
 |