Hi all,
Web development isn't my day job but I have had the opportunity to work with a few sites here and there. I've been looking at TBH and comparing it with some of the custom nTier frameworks I've seen at different places.

In my somewhat limited experience I have only seen architectures where there are things called DTOs Data Transfer Objects that move data between layers. So the DAL fills a DTO and returns a collection of DTOs to the BLL, etc.

I've been trying to learn TBH and was exasperated when I saw that the BLL was almost a straigh copy of the Entity Classes. I don't understand??? This is madness. There is a lot of coding to get the DAL and the Entity classes going and then they are copied in the BLL. Why aren't the Entity Classes just pased up the layers??? What am I missing??

jachin - frustrating as it seems, there is a perfectly logical (no pun intended) reason for this 'copy' of the entities that you are seeing. The DAL is basically mapped onto the database/xml/etc directly and as such should exactly reflect what's going on at storage level. The BLL however, does more than just mimic the DAL. Altho' it may seem from the simple examples in TBH that it is repeating itself, i'd ask you for a moment to step back and think of the BLL as the logic engine. This means that it can map onto the DAL and look at one or many providers(a good example of this being the collection comments class in the articles.cs. in larger scal apps, these relationships would be far more extensive. couple that with the fact that you may be performing calculations across different DAL objects (think of the old order/order_item scenario) and you begin to see another reason for the 'duplication'. of course, the whole object here is to have a model that adheres to the n-tier architecture and as such the BLL should not know where it get's it's data from, only how to map it's entities onto that layer below and as such it has to, to a certain extent, copy the properties that it will use to supply feedback to the UI. the BLL cannot inherit from the DAL as this would break the basic 1st rule of logical separation.

i'm sure better descriptions will follow which hopefully will illuminate the topic further - this is my 'rushing out the door' explanation :D


jimi

http://www.originaltalent.com

Don't feel bad; web development isn't my day job either. ;)

I certainly understand what you mean -- it does seem like there's a lot of duplication. But the BLL does serve a useful purpose.

Jimibt is correct when he states that the DAL objects are designed as a reflection of the DB schema; basically wrapping the tables and representing columns as properties. But let's say you'd want to include additional functionality; like, for instance, various business logic, constraints, validation, etc. While adding those to the DAL is possible, in an n-tier model, it makes more sense to implement these in the BLL. That's one reason why having middle-tier business objects makes sense.

Part of the purpose of the book is to demonstrate the implementation of a strict n-tier model. In such a model, the cardinal rule is that any layer can only reach into the layer directly below it -- in other words, no "jumping over" layers. The UI uses business objects only. The BLL uses data objects only. The DAL accesses the DB only. Allowing the UI to access the DAL directly would be a violation of the design philosophy the book is trying to demonstrate.

Again, this is ONLY a design philosophy. No one is saying that other methods are wrong, including ones that allow more transparency in the BLL and pass data objects to the UI directly. In a smaller app, that would be easier and might make a lot more sense. The n-tier model as presented in the book is far more scalable though. It would not be very hard to isolate the layers of the TBH into separate projects, and even run them on separate servers if you wanted.

I'm still a little confused here. The last framework I used did only let each layer talk to the layer below it. But they transfered the data using a business object. The BLL did all the business rules and seemed to achieve the same thing as TBH. The UI layer knew nothing of the database and made all its calls to the BLL. I am still struggling very much as to why I would repeat large amounts of code in the BLL when I could just pass a DTO around?

I guess I'm prepared to take it on face value that it is a good idea if there is maybe a codesmith template or generator that can make things a bit quicker???

jachin - without going back into the semantics of the discussion, i can inform you that there is a code generator that is aimed squarely at TBH architecture. You can pick it up here:

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

i've spoken about it before (too many times :D) so there's quite a few threads floating around here with details of alternative templates for it etc... but you can find my 'other set' of templates for it here:

www.originaltalent.com/downloads/Templates1.zip
http://www.originaltalent.com/downlo...Templates1.zip
http://www.originaltalent.com/downlo...atesAndDLL.zip

they all do slightly different things, tho' may favourite is prolly the GenericTemplates one. Give it a whirl.



jimi

http://www.originaltalent.com

jachin - what was the framework you were looking at previously?

Alex

Alex

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

It was a custom framework developed by http://www.tibs.net.au/. I'm not able to release it sorry.

One other thing to note is that Marco is trying to demonstrate how to design it if you eventually needed to change your data storage to something other than SQL 2005 (i.e. from mssql to mysql, or oracle, etc.) The ability to do this does then require the very strict separation Marco uses (which at a glance appears to be redundant). So, theoretically :) the only things you would ever have to change would be those child classes specific to the datastore (i.e. SqlArticlesProvider would become OracleArticlesProvider).