True n-tier?


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 13 of 13

Thread: True n-tier?

  1. #1
    Jason Langston Guest

    True n-tier?

    I've been reading through the posts here as well as those in other groups
    referenced here. I've been playing with n-tier/OOP concepts as I make the
    move from 2-tier to n-tier programming.
    From many of the posts I've read, it seems that in practice most developers
    are simply using a DB Layer object to call an sp, then pass the resulting rs
    to the Business Layer, which in turn passes the same rs to the Client (UI
    Layer). (A second option is to use [insert your favorite method here] to
    serialize the rs at the DB layer, and de-serialize it at the UI layer). All
    I see is 2-tier programming stretched across (possibly) several physical
    machines. Is this 'scalability' the only reason for n-tier?
    Many discussions I've read still seem to leave much of the Business Layer's
    responsibility (data validation, application of business rules) to the RDBMS
    via sp's, constraints and triggers. Yet the author's of these posts claim to
    be building n-tier apps. Are they really?
    Similarly, many of these same authors seem to feel that several objects
    passing around a recordset is OOP. Am I correct in feeling that they are
    mistaken?

    Your comments are appreciated,
    Jason Langston



  2. #2
    Richard Dalton . Guest

    Re: True n-tier?



    Jason,

    Words like True and Pure become problematic. If we've
    learned one thing it's that pure theory does not work in
    practice.

    Unfortunately when you decide that some rules can be broken
    the problem arises as to which rules to break.

    In crude terms the old optimization spectrum applies.
    You can have a blindingly fast application which uses tricks
    for speed that make the code more difficult to maintain.
    Or you can make the code more maintainable at a performance
    cost. I'm painting with very broad strokes here, so please
    let's not get hung up on what I've just said. I think it's
    basically true.

    "Jason Langston" <jasonl@NOSPAMwirelesszone.com> wrote:

    >All I see is 2-tier programming stretched across (possibly) >several physical

    machines. Is this 'scalability' the only >reason for n-tier?


    The concept of a tiered or layer architecture has been around
    for a long long time. At least as far back as 1967 in software.
    Probably longer in hardware. It's real benefit is abstraction.
    If you hide the details of lower tiers you should be able to
    swap those tiers out without affecting the higher tiers.

    Most people probably didn't notice when their phone company converted from
    analogue to digital, because the User Interface
    (The Phone) still worked in exactly the same way.

    You are right when you ask what distinguishes n-Tier from
    2-Tier client/server. The OO-ness of architectures that are being built
    has been an ongoing topic on this board.

    I think the answer to your question is that there is not
    one thing called an n-Tier architecture. There's no
    correct method of marshalling data. There's no one way
    of connecting to the Database. There's no right or wrong
    way to do Error Handling.

    n-tier is like a microcosm of software development in general. There are
    numerous ways of doing each little piece of the puzzle.
    Depending on what you want out of an n-Tier architure you will
    pick a certain way of solving each piece of the problem.

    You want to Marshall data?
    Depending on your needs, skills and prejudices you will
    probably either use:

    XML, Disconnected Recordsets, Variant Arrays, Property Bags,
    Fixed Length Strings, or some custom marshalling technique.

    I think as long as there are logical tiers then you deserve
    to call your architecture tiered. The relative quality of
    different architectures remains an issue. But we can't say
    that there is one tiered architecture and anything that solves
    some part of the puzzle differently does not qualify.

    Finally when assesing an architecture we need to look at what
    the architect was trying to achieve. Is Performance and
    scalability the goal? Is ease of development and maintenance
    the goal? Are we trying to hide implementation details behind
    a very rich domain model?

    Only when you know what problem the architecture is supposed
    to solve, can you determine it's quality. There is no silver
    bullet architecture that meets all needs.

    Hope this makes sense.

    -Richard




  3. #3
    Jason Langston Guest

    Re: True n-tier?

    Richard,
    Thanks for the reply. I've taken Microsoft classes, devoured books, and
    avidly read this and other ng's, all in search of the "right" way to do
    n-tier architecture. I've quickly discovered, as you point out, that there
    are a variety of answers as to how to implement n-tier architectures.
    My concern comes from the fact that I'm staring at two rather large
    projects, which although roughly based on existing 2-tier apps, I'm building
    from scratch. With a clean slate I'm trying to build them "right" the first
    time. But, I guess all I can do is dive in. As I've done in the past, and as
    I'm sure you've found yourself, often only experience gives the knowledge we
    need to determine what is "right" in our particular case.
    Well, time to go get my hands dirty. I'm sure I'll have many, many more
    questions, though I'll try to stick to specifics in the future.
    Thanks again,
    Jason.

    <Richard Dalton .> wrote in message news:3a77efd1$1@news.devx.com...
    >
    >
    > Jason,
    >
    > Words like True and Pure become problematic. If we've
    > learned one thing it's that pure theory does not work in
    > practice.

    <snip>
    > I think the answer to your question is that there is not
    > one thing called an n-Tier architecture. There's no
    > correct method of marshalling data. There's no one way
    > of connecting to the Database. There's no right or wrong
    > way to do Error Handling.

    <snip>
    >
    > Hope this makes sense.
    >
    > -Richard
    >
    >
    >




  4. #4
    Jason Langston Guest

    Re: True n-tier?

    Richard,
    I guess what it comes down to is that n-tier architecture can accomplish two
    different things : growing layers of abstraction/encapsulation *and*
    scalability. Whether it does one or the other, or both is in the eye of the
    beholder.
    (And I understand there is a very fuzzy line delimiting how much the two
    actually can be divorced from one another) Am I on the right track?
    Or is it that n-tier is intended for scalability, and that
    abstraction/encapsulation is really an OOP issue which is sperate from what
    we call "n-tier architecture"? (In other words, can you attain "n-tier
    architecture" with procedural programming). I realize that this is getting a
    little philosophical, but it will help me in understanding and qualifying
    what I read on the subject.
    For me it's similar to what you mentioned in another post about database
    normalization. I just got it. I may not always remember which normal form is
    which, but I have no problem (de)-normalizing a database as my gut directs
    me. I'm trying to hit the same plane with software-architecture. I'm more
    interested in exploring the intents (why), than I am the rules (how).
    Naturally, my own experience will help, but if I can learn the why from
    other's hard-earned experience so much the better.
    -Jason

    <Richard Dalton .> wrote in message news:3a77efd1$1@news.devx.com...
    >
    >
    > Jason,
    >
    > Words like True and Pure become problematic. If we've
    > learned one thing it's that pure theory does not work in
    > practice.
    >
    > Unfortunately when you decide that some rules can be broken
    > the problem arises as to which rules to break.
    >
    > In crude terms the old optimization spectrum applies.
    > You can have a blindingly fast application which uses tricks
    > for speed that make the code more difficult to maintain.
    > Or you can make the code more maintainable at a performance
    > cost. I'm painting with very broad strokes here, so please
    > let's not get hung up on what I've just said. I think it's
    > basically true.
    >
    > "Jason Langston" <jasonl@NOSPAMwirelesszone.com> wrote:
    >
    > >All I see is 2-tier programming stretched across (possibly) >several

    physical
    > machines. Is this 'scalability' the only >reason for n-tier?
    >
    >
    > The concept of a tiered or layer architecture has been around
    > for a long long time. At least as far back as 1967 in software.
    > Probably longer in hardware. It's real benefit is abstraction.
    > If you hide the details of lower tiers you should be able to
    > swap those tiers out without affecting the higher tiers.
    >
    > Most people probably didn't notice when their phone company converted from
    > analogue to digital, because the User Interface
    > (The Phone) still worked in exactly the same way.
    >
    > You are right when you ask what distinguishes n-Tier from
    > 2-Tier client/server. The OO-ness of architectures that are being built
    > has been an ongoing topic on this board.
    >
    > I think the answer to your question is that there is not
    > one thing called an n-Tier architecture. There's no
    > correct method of marshalling data. There's no one way
    > of connecting to the Database. There's no right or wrong
    > way to do Error Handling.
    >
    > n-tier is like a microcosm of software development in general. There are
    > numerous ways of doing each little piece of the puzzle.
    > Depending on what you want out of an n-Tier architure you will
    > pick a certain way of solving each piece of the problem.
    >
    > You want to Marshall data?
    > Depending on your needs, skills and prejudices you will
    > probably either use:
    >
    > XML, Disconnected Recordsets, Variant Arrays, Property Bags,
    > Fixed Length Strings, or some custom marshalling technique.
    >
    > I think as long as there are logical tiers then you deserve
    > to call your architecture tiered. The relative quality of
    > different architectures remains an issue. But we can't say
    > that there is one tiered architecture and anything that solves
    > some part of the puzzle differently does not qualify.
    >
    > Finally when assesing an architecture we need to look at what
    > the architect was trying to achieve. Is Performance and
    > scalability the goal? Is ease of development and maintenance
    > the goal? Are we trying to hide implementation details behind
    > a very rich domain model?
    >
    > Only when you know what problem the architecture is supposed
    > to solve, can you determine it's quality. There is no silver
    > bullet architecture that meets all needs.
    >
    > Hope this makes sense.
    >
    > -Richard
    >
    >
    >




  5. #5
    Jon C. Stonecash Guest

    Re: True n-tier?

    "Jason Langston" <jasonl@NOSPAMwirelesszone.com> wrote:

    >I've been reading through the posts here as well as those in other groups
    >referenced here. I've been playing with n-tier/OOP concepts as I make the
    >move from 2-tier to n-tier programming.
    >From many of the posts I've read, it seems that in practice most developers
    >are simply using a DB Layer object to call an sp, then pass the resulting rs
    >to the Business Layer, which in turn passes the same rs to the Client (UI
    >Layer). (A second option is to use [insert your favorite method here] to
    >serialize the rs at the DB layer, and de-serialize it at the UI layer). All
    >I see is 2-tier programming stretched across (possibly) several physical
    >machines. Is this 'scalability' the only reason for n-tier?
    >Many discussions I've read still seem to leave much of the Business Layer's
    >responsibility (data validation, application of business rules) to the RDBMS
    >via sp's, constraints and triggers. Yet the author's of these posts claim to
    >be building n-tier apps. Are they really?
    >Similarly, many of these same authors seem to feel that several objects
    >passing around a recordset is OOP. Am I correct in feeling that they are
    >mistaken?
    >
    >Your comments are appreciated,
    >Jason Langston
    >

    For me, the key question is what aspects of the environment of the
    application are likely to change that will cause changes in the
    application. It is late and I am tired so I will not try to list all
    of the changes but the list certainly includes technology (DBMS
    products and operating systems), business rules, and how much crap the
    application has to handle.

    When I design an application architecture, I try to look at what these
    potential changes might do to my design. The short-term goal is to
    make something that solves a current problem: this much functionality
    with this much performance. If nothing was going to change, any
    design that gets the job done would be "good enough". The reality is
    that things do change. The long term goal is to create a design that
    minimizes the impact of those changes.

    I know from experience that the database schema is likely to change.
    The design goal is to isolate the logic that deals with the database
    so that the inevitable changes do not ripple through the entire
    application. There are several general rules for the architecture
    that minimize the impact of such changes. The most important is to
    define an interface that that presents only the data that is needed
    for the function in question. SELECT * FROM EMPLOYEE is very easy to
    code, but it allows the application in question to get hooked on data
    that it does not need. Define a view or a query that returns only the
    data that is specifically required to complete the function. Define
    the contract for the interface. In almost all cases it should be
    possible to modify the database access layer to keep that interface
    constant. I really do not think that it matters if the interface is
    defined in terms of a variant array or detached recordset or XML
    string. What matters is the logical interface.

    Business logic also changes. My long term goals here are to keep all
    of the logic for a particular function in the same component so that
    it is easy to find when the changes come and to keep it separate from
    the logic for other functions. I want to be able to change the logic
    without have a huge ripple destroy everything. I do not relish
    explaining to a client that a "one line change" means that every
    component in the system must be re-built and re-released. I want to
    fix one component and release just that component and keeping on
    trucking.

    For every possible "flex" point, I want to have defined an interface
    of some kind that damps out any possible changes. Now clearly this is
    impossible to accomplish with available resources. That forces me to
    examine the probability of the change occurring. If the probability
    is small and the cost of handling the change is large, the best that I
    can do is to document the fact that when X happens, it is the end of
    the world for this application. It is not designed to handle this
    kind of change. It is time to rewrite the application. I can do this
    and sleep very well at night.

    There is no one right way to solve all problems. If my client says,
    this is a patch to solve a specific problem and it is very likely that
    this time next year, the application will no longer be needed, I write
    that down and go about my business. The client may be wrong, but if
    after a reasoned discussion, the client says, I understand the risk
    and accept the consequences of my decision, there is nothing more to
    be done. It is arrogance of the highest order to impose my judgement
    on the situation.

    This is engineering. We do the best that we can with what we have.
    We cannot do better than that.

    Jon Stonecash




    Jon C. Stonecash, Rainier Technology
    Internet: stonecash@cdev.com, Compuserve: 73014,1255

  6. #6
    Adriano Guest

    Re: True n-tier?


    My understanding is that as well as scalability, ntier promotes:

    resuable components - due to encapsulation of business logic/data access
    etc
    open architecture - you could in principle move your business layer to work
    from a SQL database to an Oracle database with no changes. Or you could denormalise
    the database without affecting the business tier - v useful.
    ease of deployment- you can easily update components on the application tier
    without client deployments

    But as for actually keeping the tier divisions strictly user/business/data,
    this is of course as idealised as a perfectly normalised database.
    - What application doesn't require some kind of client side validation that
    implements business rules?
    -What database doesn't implement business logic in stored procedures?

    That said, the distinction between tiers is extremely valid as it forms the
    first stages of the application arcitechture and can then be built on. Also
    it is instructive in that we can keep, for example, database object references
    out of the business tier. But if someone built a pure ntier app, I'm sure
    it would be crap.


  7. #7
    Richard Dalton . Guest

    Re: True n-tier?


    "Adriano" <adrian_osullivan@hotmail.com> wrote:
    >- What application doesn't require some kind of client side validation >that

    implements business rules?

    Absolutely. I hear a lot of talk about business rules as if they
    were "A thing" something that can be isolated. Perhaps they can.
    I sure haven't figured out how. As I see it "Some" Business rules
    can be implemented in the Business Tier but they are integrated
    into the actual business objects.

    Other Business rules are implemented in the Presentation Tier offering
    certain validation rules etc.

    I have never seen a beautifully implemented Business Rules Layer which
    sat on top od the Business Objects Layer. I don't really think it
    can be done.


    >-What database doesn't implement business logic in stored procedures?


    Well, I've given up on stored procedures and don't use them at all,
    but that's another story.

    >That said, the distinction between tiers is extremely valid as it forms
    >the first stages of the application arcitechture and can then be built >on.


    Yes, Sometimes theory will get you a bit of the way down the right road,
    and then leave you to find your way from there. But it's still useful
    to have started on the right road.


    >But if someone built a pure ntier app, I'm sure it would be crap.


    I can vouch for that

    The problem with n-Tier is that the more I learn, the less I know.

    -Richard


  8. #8
    Guest

    Re: True n-tier?

    >>-What database doesn't implement business logic in stored procedures?
    >Well, I've given up on stored procedures and don't use them at all,
    >but that's another story.


    I'm not a big fan of stored procs either, but they can make a pretty
    significant speed difference.

    Also, Personally, I think that a self correcting/self monitoring DB is about
    as close to perfection as you can get. I'm a big fan of triggers, in
    conjunction with stored procs and jobs for that purpose. If someone gets
    direct access to the DB and decides that he needs to remove this +one bad
    record+, I much prefer the DB to prevent it or perform the removal according
    to whatever rules we've setup. Moving that logic to a middle tier kills that
    entirely.

    I know that under tight schedules, the last thing that gets built is db
    managment tools, so if I can use enterprise manager as my DB management, I'm
    money ahead. I just like to know the DB will prevent me (or others) from
    unlinking records, screwing up relationships, etc. Triggers and stored procs
    work pretty good for that.

    Don't get me wrong. I don't have stored procs running out my ears, either.
    My current project has about 30 tables and about 15 SPs, maybe 6 triggers
    and 3 jobs (fired from triggers because there's things you just can't do
    from a trigger). I don't have a single "Insert/Update/Delete" stored proc.

    And about 9months ago, I was declaring +no stored procs+ in our DB<g>. Oh
    well.



  9. #9
    Jason Langston Guest

    Re: True n-tier?

    <Richard Dalton .> wrote in message news:3a796844$1@news.devx.com...
    >
    > I have never seen a beautifully implemented Business Rules Layer which
    > sat on top od the Business Objects Layer. I don't really think it
    > can be done.


    Aha! <light bulb going on> Just the honest, been-there-tried-that comments I
    was looking for. Thanks.

    > Well, I've given up on stored procedures and don't use them at all,
    > but that's another story.


    Why? I love'em. (See Darin's comments). To me they provide an excellent
    layer of abstraction between the actual storage details (table layouts,
    indexes) and the data access layer.




  10. #10
    Richard Dalton . Guest

    Re: True n-tier?


    "Jason Langston" <jasonl@NOSPAMwirelesszone.com> wrote:

    >> Well, I've given up on stored procedures and don't use them at all,
    >> but that's another story.

    >
    >Why? I love'em. (See Darin's comments). To me they provide an excellent
    >layer of abstraction between the actual storage details (table layouts,
    >indexes) and the data access layer.



    OK, Here's why I don't use Stored Procedures.

    Let's say you have a stored procedure which accepts an employee
    ID and returns a recordset containing the record for that employee.
    You might call the Proc GetEmployee.

    Now, what happens if you want to load a range of employees perhaps
    for a collection class. Do you implement a separate Proc. GetEmployees
    which takes in a min and max ID?

    OK, now let's say you'd also like to be able to load a collection of
    employees by their salary. Another Proc. GetEmployeeBySalary

    And on and on. Every new type of query requires a new Proc.
    And this is just the Employee table.

    I like to be able to do Adhoc queries. I can't see how these
    can be done using Procs. You need a flexible way of converting
    your query into SQL in the DBLayer.

    I've described broadly how I do this at the following URL.

    www.rdalton.com/asada/CXQMLQuery.htm



    -Richard






  11. #11
    Jacob Grass Guest

    Re: True n-tier?

    I think, to be effective, you need to use a combination of Stored Procs,
    Views, User Defined Functions, and ad hoc SQL Queries. This way you don't
    run into the problem of creating a new stored proc for every possible query.
    You can access the view and still provide some degree of abstraction . . .

    Just my opinion.

    Jacob

    <Richard Dalton .> wrote in message news:3a79e5e2$1@news.devx.com...
    >
    > "Jason Langston" <jasonl@NOSPAMwirelesszone.com> wrote:
    >
    > >> Well, I've given up on stored procedures and don't use them at all,
    > >> but that's another story.

    > >
    > >Why? I love'em. (See Darin's comments). To me they provide an excellent
    > >layer of abstraction between the actual storage details (table layouts,
    > >indexes) and the data access layer.

    >
    >
    > OK, Here's why I don't use Stored Procedures.
    >
    > Let's say you have a stored procedure which accepts an employee
    > ID and returns a recordset containing the record for that employee.
    > You might call the Proc GetEmployee.
    >
    > Now, what happens if you want to load a range of employees perhaps
    > for a collection class. Do you implement a separate Proc. GetEmployees
    > which takes in a min and max ID?
    >
    > OK, now let's say you'd also like to be able to load a collection of
    > employees by their salary. Another Proc. GetEmployeeBySalary
    >
    > And on and on. Every new type of query requires a new Proc.
    > And this is just the Employee table.
    >
    > I like to be able to do Adhoc queries. I can't see how these
    > can be done using Procs. You need a flexible way of converting
    > your query into SQL in the DBLayer.
    >
    > I've described broadly how I do this at the following URL.
    >
    > www.rdalton.com/asada/CXQMLQuery.htm
    >
    >
    >
    > -Richard
    >
    >
    >
    >
    >




  12. #12
    Jason Langston Guest

    Re: True n-tier?

    Richard,
    Hmmm.... very interesting. I just read your brief description of how your
    framework handles 'ad-hoc' queries. I understand the desire to avoid 50
    variations on
    every sp_GetEmployee. However, I can accomplish the same thing as your two
    classes (CObjectMap and CXQMLQuery) via one stored procedure. Your approach
    definitely gains your framework RDBMS vendor independence. Mine, I'm tied to
    SQL Server, unless I re-write my sp's in PL/SQL or whatever.

    To me the benefit of using the stored procedure, is that if the database
    schema needs to be
    modified (ie. (de)normalized further), I don't have to go anywhere else to
    make the update. I can check for which stored procedures will be affected,
    right there in the database (sp_depends shows the names of all db objects -
    triggers, sp's, views - which depend on that table), and make the necessary
    modifications to those stored procedures. I never have to crack open Visual
    Studio, and I don't have to do a text search through code to make sure I
    don't miss anything. IMO this ease of maintenance offsets the RDBMS vendor
    dependence.

    So I guess it comes down to where do you want to house this logic, and which
    language do you want to develop / maintain it in.
    -Jason
    <Richard Dalton .> wrote in message news:3a79e5e2$1@news.devx.com...

    > OK, Here's why I don't use Stored Procedures.

    <snip>
    > And on and on. Every new type of query requires a new Proc.
    > And this is just the Employee table.
    >
    > I like to be able to do Adhoc queries. I can't see how these
    > can be done using Procs. You need a flexible way of converting
    > your query into SQL in the DBLayer.
    >
    > I've described broadly how I do this at the following URL.
    >
    > www.rdalton.com/asada/CXQMLQuery.htm
    >
    >
    >
    > -Richard
    >
    >
    >
    >
    >






  13. #13
    test Guest

    Re: True n-tier?

    <Richard Dalton .> wrote in message <news:3a79e5e2$1@news.devx.com>...

    > I like to be able to do Adhoc queries. I can't see how these
    > can be done using Procs. You need a flexible way of converting
    > your query into SQL in the DBLayer.
    >
    > I've described broadly how I do this at the following URL.
    >
    > www.rdalton.com/asada/CXQMLQuery.htm


    Maybe you can turn them into parameterized ADO Command objects? You could
    keep a collection or Dictionary of them, keyed by the parameterized SQL
    or some kind of hash on the SQL, so you could check the collection for a
    similar query you've already prepared and reuse it.

    --
    Joe Foster <mailto:jfoster@ricochet.net> Got Thetans? <http://www.xenu.net/>
    WARNING: I cannot be held responsible for the above They're coming to
    because my cats have apparently learned to type. take me away, ha ha!



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center