Is this a good application Design?

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Mahesh P

    #46
    Re: Is this a good application Design?

    Hi all;
    Three tier architecture is very use ful for distributed application; You can
    do one thing make some common classes for common functions and use sqlhelper
    class as a DAL (Data Access Layer); dont customize sqlhelper class becauase
    this can be use for all applications.
    you can also customize your shared functions and pass sql statement as
    string and can pass perameter according to condition; but you should use
    stored procedure;


    thankx

    "Eliyahu Goldin" wrote:
    [color=blue]
    > Sometimes it is the best practice. You can change from one platform to
    > another without affecting the business logic implemented in stored
    > procedures.
    >
    > Eliyahu
    >
    > "Kim Quigley" <kimquigley@hot mail.com> wrote in message
    > news:%23n%23QjX ndFHA.4040@TK2M SFTNGP14.phx.gb l...[color=green]
    > > I wasn't aware that putting SQL in the business layer was a best practice.[/color]
    > I[color=green]
    > > use SQL Server 2000 with stored procedures and my data layer accesses[/color]
    > those[color=green]
    > > stored procedures. In the business layer, I have logical business objects
    > > with properties and methods. The purpose of having a seperate data layer[/color]
    > is[color=green]
    > > so that if your data source changes (for example: moving from SQL Server[/color]
    > to[color=green]
    > > MySQL) then you only have to modify the data layer. The presentation and
    > > business layers would be unaffected.
    > >
    > >
    > > "Josh" <s@a.com> wrote in message
    > > news:OS2sZKndFH A.3324@TK2MSFTN GP10.phx.gbl...[color=darkred]
    > > > Your SQL should be in the Business Layer. The presentation layer should
    > > > not make or provide decisions on how data is collected ( that what[/color][/color]
    > tables[color=green][color=darkred]
    > > > / view or columns are used ) as that is a business rule.
    > > >
    > > >
    > > >
    > > > "Jay Balapa" <jbalapa@hotmai l.com> wrote in message
    > > > news:%23zUYpHnd FHA.3488@tk2msf tngp13.phx.gbl. ..
    > > >> Hello,
    > > >>
    > > >> Currently my application has three tiers-
    > > >>
    > > >> 1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.)
    > > >> This predominantly contains User Controls, Custom Controls and Win/Web
    > > >> Forms.
    > > >> I have one base form and I inherit from that form.
    > > >> All validation is done in this tier. There is zero Data Access code in
    > > >> this tier. This tier exclusively gets DataViews/ Arays/Lists as input.
    > > >> Outputs are string objects with SQL Statements or just paremeters with
    > > >> dataconnection key.
    > > >>
    > > >> 2. Business Layer.
    > > >> Currently this is just a Library residing in the same machine as
    > > >> Presentation layer. Eventually I plan to use WebServices if application
    > > >> needs physical seperation.
    > > >> Most of Business Logic are implemented in this layer. There is[/color][/color]
    > absolutely[color=green][color=darkred]
    > > >> no UI code here.
    > > >> These are all bunch of static methods which perform CRUD functionality.
    > > >> All methods are atomic in nature. I dont rely on Static Variables.[/color][/color]
    > There[color=green][color=darkred]
    > > >> is just one DatabaseGateway class which does all the functionality.
    > > >>
    > > >> 3. Data Layer. (SQL Server)
    > > >> I dont use stored procedures. predominantly use Views.
    > > >>
    > > >>
    > > >> I have been reading up on Rockford Lhotka's business objects and I just
    > > >> feel that his framework is unnecessarily complex. I just dont see the
    > > >> need to hold these intermediate Business Objects.
    > > >>
    > > >>
    > > >>
    > > >> Thanks for your responses.
    > > >>
    > > >> --
    > > >> Jay Balapa
    > > >> Director Of Software Engineering
    > > >> www.atginc.com
    > > >>
    > > >>
    > > >>
    > > >>
    > > >>
    > > >
    > > >[/color]
    > >
    > >[/color]
    >
    >
    >[/color]

    Comment

    • Tony Phillips

      #47
      Re: Is this a good application Design?

      I agree. I am don't believe in putting business logic inside of the
      database. Business logic belongs in the Business Logic Layer (BLL). In
      addition, SQL commands and data access code do not belong in the BLL. A
      entity should never know how to persist itself in the database. This is why
      I am not a fan of Lhotka's CSLA framework. This breaks classic object
      oriented programming rules.

      "Chad Z. Hower aka Kudzu" wrote:
      [color=blue]
      > "bradley" <someone@micros oft.com> wrote in
      > news:#93$ARndFH A.1456@TK2MSFTN GP15.phx.gbl:[color=green]
      > > If you want to do away with the complexity of the business objects,
      > > then consider moving this business logic to the database as stored
      > > procedures and triggers.[/color]
      >
      > There are of course many schools of thought, but personally I would never recommend that. If
      > you want my views as to why, you can read the link that I just posted.
      >
      >
      > --
      > Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
      > "Programmin g is an art form that fights back"
      >
      > Blog: http://blogs.atozed.com/kudzu
      >[/color]

      Comment

      • Robbe Morris [C# MVP]

        #48
        Re: Is this a good application Design?

        This has served me pretty well as a base design for
        the software families I work on:


        --
        Robbe Morris - 2004/2005 Microsoft MVP C#
        EggHeadCafe's RSS Search Engine





        "Tony Phillips" <Tony Phillips@discus sions.microsoft .com> wrote in message
        news:A001F690-2444-41D8-A43E-DBEDC5906F0B@mi crosoft.com...[color=blue]
        >I agree. I am don't believe in putting business logic inside of the
        > database. Business logic belongs in the Business Logic Layer (BLL). In
        > addition, SQL commands and data access code do not belong in the BLL. A
        > entity should never know how to persist itself in the database. This is
        > why
        > I am not a fan of Lhotka's CSLA framework. This breaks classic object
        > oriented programming rules.
        >
        > "Chad Z. Hower aka Kudzu" wrote:
        >[color=green]
        >> "bradley" <someone@micros oft.com> wrote in
        >> news:#93$ARndFH A.1456@TK2MSFTN GP15.phx.gbl:[color=darkred]
        >> > If you want to do away with the complexity of the business objects,
        >> > then consider moving this business logic to the database as stored
        >> > procedures and triggers.[/color]
        >>
        >> There are of course many schools of thought, but personally I would never
        >> recommend that. If
        >> you want my views as to why, you can read the link that I just posted.
        >>
        >>
        >> --
        >> Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
        >> "Programmin g is an art form that fights back"
        >>
        >> Blog: http://blogs.atozed.com/kudzu
        >>[/color][/color]


        Comment

        • Robbe Morris [C# MVP]

          #49
          Re: Is this a good application Design?



          --
          Robbe Morris - 2004/2005 Microsoft MVP C#
          EggHeadCafe's RSS Search Engine





          "Tony Phillips" <Tony Phillips@discus sions.microsoft .com> wrote in message
          news:A001F690-2444-41D8-A43E-DBEDC5906F0B@mi crosoft.com...[color=blue]
          >I agree. I am don't believe in putting business logic inside of the
          > database. Business logic belongs in the Business Logic Layer (BLL). In
          > addition, SQL commands and data access code do not belong in the BLL. A
          > entity should never know how to persist itself in the database. This is
          > why
          > I am not a fan of Lhotka's CSLA framework. This breaks classic object
          > oriented programming rules.
          >
          > "Chad Z. Hower aka Kudzu" wrote:
          >[color=green]
          >> "bradley" <someone@micros oft.com> wrote in
          >> news:#93$ARndFH A.1456@TK2MSFTN GP15.phx.gbl:[color=darkred]
          >> > If you want to do away with the complexity of the business objects,
          >> > then consider moving this business logic to the database as stored
          >> > procedures and triggers.[/color]
          >>
          >> There are of course many schools of thought, but personally I would never
          >> recommend that. If
          >> you want my views as to why, you can read the link that I just posted.
          >>
          >>
          >> --
          >> Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
          >> "Programmin g is an art form that fights back"
          >>
          >> Blog: http://blogs.atozed.com/kudzu
          >>[/color][/color]


          Comment

          • Kevin Spencer

            #50
            Re: Is this a good application Design?

            Pretty good stuff, Robbe!

            --

            Kevin Spencer
            Microsoft MVP
            ..Net Developer
            Neither a follower nor a lender be.

            "Robbe Morris [C# MVP]" <info@eggheadca fe.com> wrote in message
            news:OzcH74ZuFH A.3256@TK2MSFTN GP09.phx.gbl...[color=blue]
            > http://www.eggheadcafe.com/articles/...plications.asp
            >
            > --
            > Robbe Morris - 2004/2005 Microsoft MVP C#
            > EggHeadCafe's RSS Search Engine
            > http://www.eggheadcafe.com/articles/...h/default.aspx
            >
            >
            >
            >
            > "Tony Phillips" <Tony Phillips@discus sions.microsoft .com> wrote in message
            > news:A001F690-2444-41D8-A43E-DBEDC5906F0B@mi crosoft.com...[color=green]
            >>I agree. I am don't believe in putting business logic inside of the
            >> database. Business logic belongs in the Business Logic Layer (BLL). In
            >> addition, SQL commands and data access code do not belong in the BLL. A
            >> entity should never know how to persist itself in the database. This is
            >> why
            >> I am not a fan of Lhotka's CSLA framework. This breaks classic object
            >> oriented programming rules.
            >>
            >> "Chad Z. Hower aka Kudzu" wrote:
            >>[color=darkred]
            >>> "bradley" <someone@micros oft.com> wrote in
            >>> news:#93$ARndFH A.1456@TK2MSFTN GP15.phx.gbl:
            >>> > If you want to do away with the complexity of the business objects,
            >>> > then consider moving this business logic to the database as stored
            >>> > procedures and triggers.
            >>>
            >>> There are of course many schools of thought, but personally I would
            >>> never recommend that. If
            >>> you want my views as to why, you can read the link that I just posted.
            >>>
            >>>
            >>> --
            >>> Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
            >>> "Programmin g is an art form that fights back"
            >>>
            >>> Blog: http://blogs.atozed.com/kudzu
            >>>[/color][/color]
            >
            >[/color]


            Comment

            • Chad Z. Hower aka Kudzu

              #51
              Re: Is this a good application Design?

              "=?Utf-8?B?VG9ueSBQaGl sbGlwcw==?=" <Tony
              Phillips@discus sions.microsoft .com> wrote in
              news:A001F690-2444-41D8-A43E-DBEDC5906F0B@mi crosoft.com:[color=blue]
              > I agree. I am don't believe in putting business logic inside of the
              > database. Business logic belongs in the Business Logic Layer (BLL).
              > In addition, SQL commands and data access code do not belong in the
              > BLL. A entity should never know how to persist itself in the
              > database. This is why I am not a fan of Lhotka's CSLA framework.
              > This breaks classic object oriented programming rules.[/color]

              For differing views (ones I dont agree with, but you should always consider alternate views and
              make your own choices)

              Subject: Re: n-Tier Business App - Complex Logic
              Newsgroups: microsoft.publi c.dotnet.distri buted_apps



              --
              Chad Z. Hower (a.k.a. Kudzu)
              "Programmin g is an art form that fights back"

              Stuff: http://www.KudzuWorld.com
              Blogs: http://www.KudzuWorld.com/blogs

              Comment

              Working...