Is this a good application Design?

Discussion in 'ASP .Net' started by Jay Balapa, Jun 21, 2005.

  1. Jay Balapa

    Jay Balapa Guest

    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 absolutely 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. There 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, Jun 21, 2005
    #1
    1. Advertisements

  2. Jay Balapa

    Josh Guest

    Your SQL should be in the Business Layer. The presentation layer should not
    make or provide decisions on how data is collected ( that what tables / view
    or columns are used ) as that is a business rule.
     
    Josh, Jun 21, 2005
    #2
    1. Advertisements

  3. Jay Balapa

    Jay Balapa Guest

    Josh,

    Thanks for your response.

    SQL most of the time is in the Business layer.

    Sometimes I need to iterate Datarows in a Datagrid. In those cases I make
    that exception.
     
    Jay Balapa, Jun 21, 2005
    #3
  4. Jay Balapa

    bradley Guest

    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.
     
    bradley, Jun 21, 2005
    #4
  5. Jay Balapa

    Kim Quigley Guest

    I wasn't aware that putting SQL in the business layer was a best practice. I
    use SQL Server 2000 with stored procedures and my data layer accesses those
    stored procedures. In the business layer, I have logical business objects
    with properties and methods. The purpose of having a seperate data layer is
    so that if your data source changes (for example: moving from SQL Server to
    MySQL) then you only have to modify the data layer. The presentation and
    business layers would be unaffected.
     
    Kim Quigley, Jun 21, 2005
    #5
  6. Jay Balapa

    Josh Guest

    Keeping the layers truely seperate is difficult. I would suggest that even
    if you have to itereate through a result set the SQL should be in the
    Business Layer, pass your filter criteria to the business layer.
     
    Josh, Jun 21, 2005
    #6
  7. Chad Z. Hower aka Kudzu, Jun 21, 2005
    #7
  8. Views are good - BUT with SQL Server result set based stored procedures are typcially better
    because of SQL servers optimization techniques. Newer versions are adressing this, but as to how
    much I dont know yet.
     
    Chad Z. Hower aka Kudzu, Jun 21, 2005
    #8
  9. There are opposing schools of thought here. You will find advice telling you both ways, and some
    saying to mix it.
     
    Chad Z. Hower aka Kudzu, Jun 21, 2005
    #9
  10. 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 aka Kudzu, Jun 21, 2005
    #10
  11. I'm only starting on Lhotka's book (which Jay here mentions), but I
    think the author recommends putting the data access in with the
    Business Objects, but only as static CRUD methods. Then, the
    assemblies are duplicated on the three "internal" layers (Presentation,
    Business, Data Access). Unknown whether it is a best practice or not,
    however it allows the actual "instantiatable" BOs to be fully
    black-box, while still allowing the data access code full access to the
    BO's internals ... at least how I'm reading it.

    So far (about 80 pages in), the book is quite good.
     
    Chris Simmons, Jun 21, 2005
    #11
  12. Jay Balapa

    Steve Walker Guest

    Agree. For one thing, TSQL is a horrible language to do anything
    non-trivial in.
     
    Steve Walker, Jun 21, 2005
    #12
  13. Which is one of the many points I point to in the article (or PL/SQL, or whatever)
     
    Chad Z. Hower aka Kudzu, Jun 21, 2005
    #13
  14. Not quite... You can make calls to .NET procedures FROM STored procedures... But even then its not
    a good idea in most cases to put your logic in SPs.
     
    Chad Z. Hower aka Kudzu, Jun 21, 2005
    #14
  15. Jay Balapa

    bradley Guest

    T-SQL is an excellent language for implementing business logic that is tied
    closely to the database model or database processing. For example, imposing
    data constraints or referencing a set of parameters against a lookup table
    and returning a value. Of course, it helps is the developer is at least an
    intermediate level SQL programmer and familiar with sub-queries, complex
    joins, conditional grouping and where clauses, etc.
     
    bradley, Jun 21, 2005
    #15
  16. Jay Balapa

    Steve Walker Guest

    Not terribly portable though, is it?
     
    Steve Walker, Jun 21, 2005
    #16
  17. I dont think you will find many that agree with you. C#, Java, anything is better at business logic.
    Data level storage constraints are not business logic.
    Data lookups are not business logic.
     
    Chad Z. Hower aka Kudzu, Jun 21, 2005
    #17
  18. Jay Balapa

    Jay Balapa Guest

    moving this business logic to the database as stored procedures and
    Problem with that approach is our application will have to support ACCESS as
    well as SQL Server, in future we might have to deal with Oracle.

    We program exclusively on interfaces and not on actual SQL or OLE objects.
    By using simple Views we can mask the changes in underlying tables if
    needed.

    -jay
     
    Jay Balapa, Jun 21, 2005
    #18
  19. Jay Balapa

    bradley Guest

    Data lookups are not business logic.

    It can be if the business logic is implemented as meta data tables rather
    than hard coded conditional branching and looping.
     
    bradley, Jun 21, 2005
    #19
  20. I am not sure what are you getting to by insisting on moving the SQL to the
    business layer. It looks to me like insisting on the dotnet framework to
    belong to one layer only.

    A database consists of tables, view, stored procedures, triggers etc. Tables
    and views belong to data layer. Stored procedures and triggers can be in
    either data or business layer. It won't hurt the SQL server if it will
    contain elements of both levels.

    Eliyahu
     
    Eliyahu Goldin, Jun 21, 2005
    #20
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.