Thread: Approaching THB
View Single Post
  #10 (permalink)  
Old September 24th, 2007, 04:46 AM
jimibt jimibt is offline
Friend of Wrox
 
Join Date: Mar 2007
Location: Creetown, UK
Posts: 488
Thanks: 2
Thanked 11 Times in 10 Posts
Default

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