The simple stuff

Discussion in 'ASP .Net' started by Rowan, Jul 2, 2007.

  1. Rowan

    Rowan Guest

    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.
     
    Rowan, Jul 2, 2007
    #1
    1. Advertising

  2. 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/
    ======================================
    "Rowan" <> wrote in message news:...
    > 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.
    >
     
    Juan T. Llibre, Jul 2, 2007
    #2
    1. Advertising

  3. 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



    "Rowan" wrote:

    > 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.
    >
    >
     
    =?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=, Jul 2, 2007
    #3
  4. Rowan

    Rowan Guest

    On Jul 2, 1:02 pm, Peter Bromberg [C# MVP]
    <> wrote:
    > 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


    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.
     
    Rowan, Jul 2, 2007
    #4
  5. See some comments below:

    Ysgrifennodd Rowan:
    > Hi there,


    <snip />

    >
    > 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?
    >


    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.
    >


    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
     
    Peter Bradley, Jul 2, 2007
    #5
  6. Rowan

    Rowan Guest

    On Jul 2, 3:06 pm, Peter Bradley <> wrote:
    > See some comments below:
    >
    > Ysgrifennodd Rowan:
    >
    > > Hi there,

    >
    > <snip />
    >
    >
    >
    > > 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?

    >
    > 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.

    >
    > 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


    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, Jul 3, 2007
    #6
  7. Rowan

    Otavio Decio Guest

    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" <> wrote in message
    news:...
    > 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.
    >
     
    Otavio Decio, Jul 3, 2007
    #7
  8. Rowan

    Rowan Guest

    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.
     
    Rowan, Jul 5, 2007
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. ALuPin
    Replies:
    4
    Views:
    851
    Nachiket Kapre
    Jul 13, 2004
  2. Tom  Verbeure

    Re: Programable Logic & Video stuff

    Tom Verbeure, Jul 12, 2004, in forum: VHDL
    Replies:
    1
    Views:
    481
    john jakson
    Jul 13, 2004
  3. defcon8

    simple stuff in swing

    defcon8, Nov 5, 2005, in forum: Java
    Replies:
    11
    Views:
    708
    Roedy Green
    Nov 6, 2005
  4. Larry
    Replies:
    1
    Views:
    366
    Finnbarr P. Murphy
    Feb 21, 2004
  5. LC

    simple stuff !!!

    LC, May 14, 2008, in forum: VHDL
    Replies:
    13
    Views:
    855
    rickman
    May 17, 2008
Loading...

Share This Page