Hi,

I'm trying to learn the whole DAL architecture and make sure I really understand and the relationship between objects and relations, and I have a few questions. I've been reading MArtin Fowler's enterprise arch book and am trying to work out what patterns are being used.

I /think/ TBH uses Table Gateways but if so, I don't get why in ArticleDetails.cs it represents data from more than one table e.g. it contains Category Title from the Categories table, yet the Articles class lazy loads Category Title anyway, so why is it needed in ArticleDetails? The stored proc is doing an inner join on articles and categories.

Also regarding the Providers, does TBH have just one ArticlesProvider covering all 3 entities for simplicity or is this achieving some deliberate purpose? I figure this has all been done for a very good reason, but I'm a bit in the dark as to why. I was thinking about how I might implement the DAL and came up with:

DAL:
ArticleProvider, CommentProvider, CategoryProvider (the table gateways - direct mapping to DB structure - no additional fields e.g. Category Title)
SqlArticleProvider, SqlCommentProvider, SqlCategoryProvider
ArticleDetails, CommentDetails, CategoryDetails (populated by table gateways)

BLL:
Comment.cs, Category.cs, Article.cs (which has a Category object and list of Comment, which come from a lazy load)
Here I build up my domain objects so that Article objects have the Category and list of Comment objects for that Article.

The reason I would do it like this is because then I have a nice simple model which I could extend to include a photo app and blog which share tags, by using a code generator (e.g. easy for me to write a script if there was a single table adapter for each table, and corresponding ObjectProvider and SqlObjectProvider classes) and I could handle the logic to get/store related data in the BLL. The way the DAL is currently done (one provider class per entity, and stored procs getting data from multiple tables) would probably need to be done by hand because of the custom fields from >1 table in some of the table adapters.

So my questions (and there are quite a few!) are:
- What DAL pattern does TBH use (beyond the provider model)?
- Why does ArticleDetails have a Category Title property when the Article class in the BLL lazy loads this on request? Is this not redundant?
- Does my approach make sense, and if not what am I missing? Ultimately I'm trying to understand the DAL, and would really like to code-generate it as a learning exercise.

I am relatively new to all of this and hope I haven't completely missed the point! I'd appreciate your thoughts :)

Rich

p.s. jimibt if you are reading this then you will be pleased to know I am trialling Flixon! However to help me learn the nuts and bolts I'm ripping up the code to see what I find :)

Having re-read Chapter 3 (p55) of the book I've seen where I was going wrong (TBH is not using table adapters and data transfer objects). Likewise multiple providers would mean I have multiple lines in the web.config and makes creating an instance by reflection problematic and frankly is not very elegant. What is the specific pattern name it uses though? I'd like to study it in more detail.

I'm still left with the question about how the DAL might be automated when I need classes like ArticleDetails, ProductDetails and OrderDetails to wrap data in multiple tables. When I used .netTiers for a similar example, it worked, but it generated about 5 million classes. There is surely a simpler way. I'm looking at Flixon which sounds like it will suit my needs for this particular case, but I'd like to get my head around how I might approach doing it myself. This presumably is a recognised problem with a known solution that can be solved without using an ORM tool.

Cheers!

Rich,

if you haven't already, i'd urge you to look at the gof (gang of four) material, as well as the excellent (and very simplified) 'head first c#'.

of course, martin fowler needs a look in too. many of these patterns are employed in the TBH architecture (take the singleton pattern in the DAL instance provider as an example) and you'll start to recognise them and where to use them with repeated exposure (actually just remembered another nice little title judith bishop - c# 3.0 design patterns)

happy 'foraging'. hope you're finding the site generator a useful tool both as an educational as well as practical example of building core BLL/DAL plumbing code!! I find that i tend to heavily model my sqlserver database (with FK's etc) with a view to how i want it to be represented in the BLL. funnily enough, it always (usually) ends up with a very nice relational design (in the database) almost by accident as a result.

anyway, have a look at those links above if you're not already au-fait with them, they'll give you food for thought.

Thanks for the links, I've been taking a look :) I have Head First Design Patterns and Martin Fowler's book on their way to me in the post which should keep me busy for a while. I also came across the doFactory website last week and like what I see, though I should probably resist the urge to spend yet more money on the same topic. This is the first time in at least 7 years that I've written any "serious" code, and the whole patterns thing became popular after I graduated so is a completely new topic to me. Still, it's really interesting stuff and makes things a damn sight easier to learn and put into practice than they used to be.

Any thoughts on my ArticleDetails question? I have been reflecting on it more and I see that it makes sense to model the entity as we want to use it in the BLL, and not according to the DB tables (because of the object/relation mismatch) hence the approach taken in TBH. I figure that is the answer to my question. In which case when following that architectural approach, another option for the DAL is to first design the BLL entities that I want then map them to DB tables. I know I can do this with e.g. NHibernate, but maybe this is a decent route to take with a code generator too? Maybe I have been trying to solve this problem the wrong way round.

Quite frankly, I don't think the TBH architecture in general neatly fits into any of the so-called "design patterns." If you really wanted to, you could say it is probably closest to the Active Record pattern, with a little Domain Model thrown in. ;-) The lack of a true service layer in the BLL is what really keeps it from being a true domain-driven application.

Also, as a rule, I would prefer using an ORM like NHibernate over DAL code generation. Building a custom DAL is hard, and it's even harder to generate code from an existing dB without knowledge of the BLL that will consume it.

Plus, with a true, full featured ORM you get a lot of functionality out of the box that a code-generated DAL might not provide. The TBH data layer is lacking in several important aspects that IMHO make it unsuitable for an enterprise-level application that needs to scale. There are no transactional semantics beyond that provided by the .NET framework itself. There is also no concurrency handling at all.

TBH is a great learning tool, don't get me wrong. But you need to keep in mind its limitations.

Lee Dumond:

Also, as a rule, I would prefer using an ORM like NHibernate over DAL code generation. Building a custom DAL is hard, and it's even harder to generate code from an existing dB without knowledge of the BLL that will consume it.

Plus, with a true, full featured ORM you get a lot of functionality out of the box that a code-generated DAL might not provide. The TBH data layer is lacking in several important aspects that IMHO make it unsuitable for an enterprise-level application that needs to scale. There are no transactional semantics beyond that provided by the .NET framework itself. There is also no concurrency handling at all.

Over the last week or so I have come to more or less the same opinion: the ideal situation is when I have a great set of business objects to work with and the DAL has neatly faded into the background (perhaps a gross simplification of the subject!). Code generators working from DB structures just don't do this (cos your BOs look exactly like the data tables). In the end I created an XML document to describe my BOs (loosely based on a CodeSmith entity template) which I then customised so the BLL took the focus of the design and the DAL fitted in. This has worked out ok but in the end I think I saved about minus 4 days of development vs. doing it "by hand".

In the last few days I've been looking at NHibernate as I do exactly this: focus the attention on the business objects, and let the ORM map to the DB. I do like the simplicity of TBH, but the features of ORM tools give me much more that I could shoehorn into TBH myself, plus take away the maintainability aspect from my code which is a major plus. ... hence why I came to appreciate being able to do the same in NHibernate in a fraction of the time.

I did try out .NetTiers briefly but what gets produced is a maze of partial classes and (as far as I could tell) not a very intuitive way of accessing the underlying data, because the BOs are basically wrapped up DB tables. I might take a look at it again in a few months once I have a bit more experience working with DALs as there seem to be plenty of .NetTiers evangelists out there who would tell me I'm wrong.

It's been an interesting exercise though!