The simple stuff

  • Thread starter Thread starter Rowan
  • Start date Start date
R

Rowan

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.
 
re:
!> I guess to start...where do I put the Mycompanyname.Common.dll?

If you only are going to use it in one application, in the application's /bin directory.
If you're goping to use it on more than one application, in the GAC.

re:
!> 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?

See above. You can use either location.
The /bin directory makes it easier to update the assembly if there's changes to it, though.

re:
!> Does that mean that I put the BLL dll in GAC since it will be referenced by both presentation layers?

Again, it doesn't matter.
You should have no problems with either location.

That's one of the great advantages to having true OOD, which VB6 had only an inkling about.




Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
======================================
 
It sounds to me like you are biting off more than you are really prepared to
chew here. I'd recommend searching for, downloading, and reviewing OPC (other
people's code) for starters and get a good perspective on how they are doing
this N-Tier "stuff". After spelunking some pretty good code, you'll have a
much better perspective on how you think you should go about yours.
-- Peter
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder(BETA): http://www.blogmetafinder.com
 
It sounds to me like you are biting off more than you are really prepared to
chew here. I'd recommend searching for, downloading, and reviewing OPC (other
people's code) for starters and get a good perspective on how they are doing
this N-Tier "stuff". After spelunking some pretty good code, you'll have a
much better perspective on how you think you should go about yours.
-- Peter
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder(BETA): http://www.blogmetafinder.com
Click to expand...

Forgive me if I seem testy but I don't understand why you put the
effort into typing your response. I have searched for, downloaded,
and reviewed MANY OPC. I understand exactly what the architecture is
supposed to be and why. When it comes to coding I cast about for best
practice and who seems to have the cleanest and most efficient code to
learn from because I want whatever I do to be solid, consistent, and
clear. I have spent hours and hours and hours working on absorbing
the .Net Framework. It is a lot of information to synthesize. If I
post it is because I am looking for some clarification, help, advice,
or possibly affirmation so I don't go about wasting too much time down
the rabbit hole. Sometimes it only takes an experienced person one
paragraph of explanation to put it all together. I was not expecting
but hoping for that. Whether I bit off more than I can chew is
moot...I can either find a way to chew it or spit it out. I would
prefer to keep my job.
 
See some comments below:

Ysgrifennodd Rowan:
Hi there,
Click to expand...

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?
Click to expand...

I've noticed that people coming from a VB6/ASP background always feel
the need for a "constants container" of some sort. I'm curious to know
what these constants might be. Of course if they're specific to your
application, then putting them in a static class might be a good idea -
but have you ever thought about using an App.config file? Is there a
reason why you wouldn't want to do that?

As to where you put things, you really don't have to worry too much
about that. We usually sign our stuff and put it in the GAC, but you
don't have to. If you decide not to, then VS will put everything in the
right place for you.
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.
Click to expand...

I know there are lots of programmers who are miles better than I am, and
who can put programs together with the bare minimum of requirements
specifications and design documents. I can't do that. I have to build
a model of my application: and I happen to use the UML to do it,
althought there are plenty of other modelling languages that might be
equally valid. My model tells me what layers I need and how they should
relate to each other. Although most of the stuff we write uses a
three-tier architecture this definitely doesn't mean that each layer
contains a single class - and sometimes it means that some layers have
more than one assembly.

<snip />

I don't know if any of this helps, but you could look at the stuff I've
produced for our programmers at work:

http://www.peredur.uklinux.net/FormsAuthenticationSln.zip

(Deals with Forms authentication in ASP.NET apps, but has a fairly
well-defined data layer and uses typed datasets. This contains a full
VS solution with its own minimal Access database. I can't guarantee its
freedom from malicious code. You must inspect it and recompile it
yourself to make sure it is safe. I wouldn't knowingly infect you with
anything, but I can make no guarantees.)

http://www.peredur.uklinux.net/TypedDataSets.pdf

(Some notes on the use of typed datasets)

http://www.peredur.uklinux.net/Remoting.pdf

(Some notes on the use of .NET remoting for a distributed 3-tier
architecture)

And lastly, you might find some bits of the following link useful, since
it shows one particular implementation of a 3-tier architecture.
However it was done using .NET 1.1 and is rapidly getting out-of-date.
It is also mostly very long and boring, so I suggest you only flick
through it (if you look at it at all) and cherry pick any bits that take
your fancy. The full code is included in the appendices.

http://www.peredur.uklinux.net/msc/

HTH


Peter
 
See some comments below:

Ysgrifennodd Rowan:


<snip />




I've noticed that people coming from a VB6/ASP background always feel
the need for a "constants container" of some sort. I'm curious to know
what these constants might be. Of course if they're specific to your
application, then putting them in a static class might be a good idea -
but have you ever thought about using an App.config file? Is there a
reason why you wouldn't want to do that?

As to where you put things, you really don't have to worry too much
about that. We usually sign our stuff and put it in the GAC, but you
don't have to. If you decide not to, then VS will put everything in the
right place for you.


I know there are lots of programmers who are miles better than I am, and
who can put programs together with the bare minimum of requirements
specifications and design documents. I can't do that. I have to build
a model of my application: and I happen to use the UML to do it,
althought there are plenty of other modelling languages that might be
equally valid. My model tells me what layers I need and how they should
relate to each other. Although most of the stuff we write uses a
three-tier architecture this definitely doesn't mean that each layer
contains a single class - and sometimes it means that some layers have
more than one assembly.

<snip />

I don't know if any of this helps, but you could look at the stuff I've
produced for our programmers at work:

http://www.peredur.uklinux.net/FormsAuthenticationSln.zip

(Deals with Forms authentication in ASP.NET apps, but has a fairly
well-defined data layer and uses typed datasets. This contains a full
VS solution with its own minimal Access database. I can't guarantee its
freedom from malicious code. You must inspect it and recompile it
yourself to make sure it is safe. I wouldn't knowingly infect you with
anything, but I can make no guarantees.)

http://www.peredur.uklinux.net/TypedDataSets.pdf

(Some notes on the use of typed datasets)

http://www.peredur.uklinux.net/Remoting.pdf

(Some notes on the use of .NET remoting for a distributed 3-tier
architecture)

And lastly, you might find some bits of the following link useful, since
it shows one particular implementation of a 3-tier architecture.
However it was done using .NET 1.1 and is rapidly getting out-of-date.
It is also mostly very long and boring, so I suggest you only flick
through it (if you look at it at all) and cherry pick any bits that take
your fancy. The full code is included in the appendices.

http://www.peredur.uklinux.net/msc/

HTH

Peter
Click to expand...

The reason I have the constants static class is because of a sample
app I found by Damon Armstrong that was put together well. The
majority of the many responses to it were very positive and it made
sense so I formed my plan using his structure as a backbone. I don't
particularly have the need to have a constants container. In DAL and
BLL he uses the constants to set db values that are null and then
check against them when updating records to be sure to save nulls back
to database. There may be a better way to do this but it was the
first sample I came across with excellent documentation to go along
with the app. It was in c# but it still made sense. I figure the
reason not to put it in the app.config file is because both the BLL
and DAL reference it. I know some people put them together but if I
ever want to remote to it which I might I should keep it separate.

http://www.simple-talk.com/dotnet/....plication-architecture-the-data-access-layer/

I will definitely take a look at what you have. I am sure it will
help. Thank you very much.
 
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
 
Thank you very much. After researching reflection more I see how this
is a better approach for my needs. I like it. I am very glad I
posted. Thank you all for your responses. They help so much.
 
Back
Top