p2p.wrox.com Forums

p2p.wrox.com Forums (http://p2p.wrox.com/index.php)
-   BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0 (http://p2p.wrox.com/forumdisplay.php?f=264)
-   -   Approaching THB (http://p2p.wrox.com/showthread.php?t=62151)

philthy September 19th, 2007 04:19 AM

Approaching THB
 
How did you guys first start tapping in to THB? What was your angle?

I first startet to read the book, but quickly found out that I needed to download the application to accompany the book.

However, I tend to get overwhelmed sometimes, and I loose track.

Are there some good tricks to approach and dissect an application like this?




jimibt September 19th, 2007 06:41 AM

philthy - i mentioned in a post a while back about how i arrived at TBH. basically, i'd been looking for a good' framework that covered the bases of well organised n-tier design as well as being object oriented and logially set out. i have only dipped into the book where i've needed to understand something more clearly and tend to use the book more as a reference rather than a tutorial. to this end, the book is a great user guide/manual and i certainly would keep it to hand for the odd issue that i can't quite figure out.

as far as tricks are concerned. once you understand the relationships between the DAL classes and the associated BLL layer, then you actually realise that the 'pattern' in play is actuall quite elegant and simple (in concept). to this end, you should be able to break at any part of the code and have a 'mind-map' of the generic route that took you that part of code, as well as knowing where the code will go from there. a great way to understand this is to just look at the posts related code and follow the logic from the BLL (\Forums\Post.cs)->DAL (ForumsProvider.cs)->\SQLClient\SqlForumsProvider.cs.

this discrete tracking of events allows you to see that basically the whole framework is composed of building blocks that behave in an identical manner. as such, this framework is very easy to template which means that new functionality can be added with the benefit of it fitting exactly like the existing code. i do keep going on and on about it, but if you want to see this 'templating' in action, then download the flixon site generator. this creates the BLL/DAL for any table that you care to point it too, as well as creating basic CRUD forms to test the data (or tweak into working pages if needbe). you can find it here:

http://www.flixon.com/site-generator/

actually, using this generator might help you understand what i was saying above as it would allow you to pick just the tbh_posts table and create all the required classes for that. then you could look at what was there without all the 'fizz' of everything else.

hope this helps.

jimi

http://www.originaltalent.com

philthy September 19th, 2007 11:22 AM

Thanks alot there, jimi…

I think you’re right, understanding the architecture will make it easier to understand how the application works.

Maybe that’s why I’ve been stuck in chapter 3. I haven’t been playing enough with the application, and it’s hard to fit the pieces together, when you don’t have an example to back up what you read.

I never made it as far as the forums part of the book… I think I’ll skip ahead and check out that forum.

Also, I’ll check out that site generator you mentioned.
I think it will give a great understanding to see things without all the distortion.
That’s one of the reasons I get a little overwhelmed when I look at the code in VWD. It’s hard to get a grip, when you just step into the code like that. Kind of like learning to swim by jumping of a boat…

Thanks for the kick in the right direction
:)


ViagraFalls September 19th, 2007 01:52 PM

Can you give us an idea of exactly what part of the architecture you're having trouble with?

Perhaps we can help you understand the reasoning behind some of the choices made :)



http://entropia-online.blogspot.com/

Maxxim September 19th, 2007 04:16 PM

Quote:

quote:
Are there some good tricks to approach and dissect an application like this?
If you just want a site... Don't waist time trying to learn the core.
If you want to improve your asp.net skills, try to imagine a bigger site than TheBeerHouse.

Then, at the some time that you are reading the book, try to improve some settings in order to have this objective site that you designed...

By that, you are forced to read the same lines of code a couple of times! And try to understand why all this!

Don't worry, i read version 1, and only later I understand the logical of DAL, BLL, etc etc!

One more thing: When I finally understand some things on asp.net 1.1, I changed to asp.net 2 and now i just think that i'm completely newbie....

If you like asp, go ahead!

Good luck


rocco50 September 20th, 2007 12:20 PM

Quote:

quote:Originally posted by jimibt
actually, using this generator might help you understand what i was saying above as it would allow you to pick just the tbh_posts table and create all the required classes for that. then you could look at what was there without all the 'fizz' of everything else.

hope this helps.

jimi

http://www.originaltalent.com
Jimi,

I really would like to be able to use this generator, but every time I try it, it doesn't work. Could you please post a walkthrough for what you suggest doing above?

Here's what I do:
1) Run Site Generator


2) Leave the default namespace: MyAppNameSpace
3) My Database Server is machine_name\SQLEXPRESS
4) I click on DB Path/Name button and select the TBH_Web\App_Data\ASPNETDB.MDF
5) Site Generator informs me:

The Database Entry is now saved.
Restart Application to use this new entry.
You will not need to do this again unless you change the databasename and/or detach the database.

I am not sure what this means, but I click OK.


6) Site Generator exits.
7) I run Site Generator again, and this time click Next
8) The app asks me to enter Providers.
9) I enter Posts in the Provider 1 Name field and click Next
10) I get a grid with table names and selection lists to select providers next to the table names.
11) The table names appear to be some system tables - MSreplication_options, spt_monitor, etc..
12) I am not sure what all this has to do with TBH ???

Alex

- TheBeerHouse Mods Repository
http://www.sashka.com/TheBeerHouse/thebeerhouse.html

jimibt September 21st, 2007 03:37 AM

alex,

right, sounds a bit odd. you should be able to see the TBH tables in that view too. just wondering if there's a 'conflict' in the name of the mdf file (i.e. the aspnetdb namespace is already perhaps registered to another db installation somewhere. as a 1st approach, i'd try to copy your working TBH database as beerhouse.mdf (along with the ldf file). and then try pointing to that to see what happens.

let me know how you get on.


jimi

http://www.originaltalent.com

philthy September 24th, 2007 02:22 AM

Quote:

quote:Originally posted by ViagraFalls
 Can you give us an idea of exactly what part of the architecture you're having trouble with?

Perhaps we can help you understand the reasoning behind some of the choices made :)



http://entropia-online.blogspot.com/
I think what confuses me the most, is the provider model. So, in order to get the full benefit of TBH, I need to study this particular topic more.




ViagraFalls September 24th, 2007 04:14 AM

philthy - Just to make sure we're talking about the same thing here. When you use the term "provider model", you mean the Data Access Layer?

If so, the reason this setup is chosen lots of times is that lots of web developers cannot be entirely sure which underlying database platform their clients use. Some use SQLServer, some will use Oracle, yet others run on Progress, and some use mySQL (or any other flavour).

By introducing a seperate provider model, the developer can ensure that the code to access and execute SQL stataements (or stored procedures) against the underlying database can be optimized per database platform. There might be other ways to index, or there might be differences in the database platform's implementation of the ANSI SQL language.

Thus, after you create the database providers, the rest of your code does not have to know what it is running against. All of that has already been handled. This means the Data Access layer can then focus on just retrieving and storing the data.

In turn, the Business Logic Layer, also doesn't need to know where the data comes from. It just accesses the DAL, pulls out the data, and then can ensure the data matches all the business rules in place.

The UI is just that; a user interface. It knows it gets proper data, and it presents it.

By seperating things into layers like this, when a business rule changes, there's a good chance there's only one spot (the BLL) where you need to change code. All the other layers remain the same. This means much less administrative overhead, and reduces the chance of breaking your existing code.

Should you want some more info, don't shun to ask :)

Peter

http://entropia-online.blogspot.com/

jimibt September 24th, 2007 04:46 AM

Peter,

Nicely summerised. I think i'd add one more level of detail (re the DAL). That being that the DAL is abstracted into two distinct functions, one to retrieve the data (as per the platform specific database i.e. DAL\SQLClient\SQL*.cs), the other part (DAL\*.ClassProvider.cs) defining the methods that will be visible (as overrides and static methods) to both the DAL and BLL. So your application (as the consumer) will only ever access the BLL layer which in turn 'looks' for the corresponding method signature in the DAL\*.ClassProvider.cs class. to all intents and purposes, the methods in the SQLClient classes are invisible to the application, even tho' they are defined as public (override).

Hopefully, (in my imagination anyway!!), this should (together with peter's comprehensive expanation above) make it a whole lot clearer.

[edit] - so what we have is:

(DAL\Provider) -public abstract class PostsProvider : DataAccess
(DAL\SQLClient\) - public class SqlPostsProvider : PostsProvider

This association 'links' these two sets of classes together, with the override definition in the SQLClient classes 'working' against any call to the public abstract methods defined in the 'base' DAL classes. The BLL link is a no brainer, it purely links directly as an exposed class (e.g. MB.TheBeerHouse.BLL.Posts) to the application and each method within it 'queries' the SiteProvider.Posts.something for it's data (SiteProvider.Posts belonging to the DAL folder i.e. one level above the DAL\SQLClent folder).

Hope this further explains the linkage. (a diagram would speak a thousand words on this one)

jimi

http://www.originaltalent.com


All times are GMT -4. The time now is 08:45 AM.

Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.