Rowan,
As your subject line calls for, here some simple stuff I learned over the
years:
The DAL: gotta have one, as you probably noticed. If you want to preserve
your sanity, make the Data Access Objects unaware of where they come from or
where they go to. Some people make (IMHO) the mistake of polluting the DAO's
with SQL - CRUDs, stored procedures. Your DAO model should at a minimum
reflect what is in your database and help your presentation layers to do
some sanity check before bugging the database.
Here's the fun part: the DAL actually is a factory that produces Data Access
Objects as well as consume them to update, insert or delete. You either
build the DAL with SP's (argh), straight SQL (hmm little better) or
reflection (my preferred method). Again, the DAL produces and consumes
objects from the DAO model.
Now look at your BLL: it is free to perform its business functions using the
objects but not caring about the mechanics of retrieving or storing. Since
the DAOs are pure, they can be easily serialized and bound to your
presentation. Which means your presentation knows about the DAL and the BLL
(and the DAO model).
Now, in regards to Common... think a little harder about this - do you
really need that? What are those constants for? Can you put them in a config
file? Or in a resources file? Having a Common class increases coupling and
reduces cohesion.
<flame alert>Whatever you do, stay away from the Microsoft Enterprise
Framework </flame alert>
Otavio
"Rowan" <phantomtoe@yahoo.comwrote in message
news:1183404358.973814.93600@o11g2000prd.googlegro ups.com...
Quote:
Hi there,
>
I am planning/building an n-Tier system with 2 presentation layers
(web, windows) which will share the BLL and DAL. This is my first
experience with .Net. As a VB6er I had to work hard to gain an object
oriented perspective. I am sure that will get stronger as I
progress. I've spent quite a bit of time studying the framework. But
now I find I am struggling with the simple things. I am in a small
company and therefore have no one's experience to learn the easy stuff
from. I've read many articles and postings trying to glean this but
find myself still unsure.
>
I started building the DAL. It references a class library containing
constants Mycompanyname.Common I think I referenced by putting
"Imports Mycompanyname.Common" in the DAL namespace but I don't
actually know what else to do here. I have so many questions here I
don't even know quite where to start or how to slim it down to the
nitty gritty. I guess to start...where do I put the
Mycompanyname.Common.dll? I know there is more than one place to put
it depending upon whether it is a private assembly or not. Both my
DAL assembly and BLL assembly will reference the Mycompanyname.Common
assembly. Would that mean it should not be private? Do I need to put
the .Common dll somewhere first and then add it to the DAL Reference
folder?
>
How do I handle the BLL/DAL dll? The way I see it the BLL references
both the DAL and the .Common. The DAL references the .Common. The
presentation layers reference the BLL. Does that mean that I put the
BLL dll in GAC since it will be referenced by both presentation
layers? I think there is probably an SNL skit here somewhere.
>
I would truly appreciate any help or guidance here. I am sure many of
you have a standard process that you step through at each point of
development. I would like to follow a strong example so I can be the
same for the other VB6er in my company and to be as good as I can be
at this.
>
