DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 4 of 4

Thread: 3-Tier Architecture Help

  1. #1
    Andy Guest

    3-Tier Architecture Help


    I am developing a medium/large scale stand-alone application which will contain
    3 logical tiers (Presentation/Business/Data), but only 1 physical tier (app
    and SQL server running on same computer) for now. It is highly likely in
    the near future the SQL server will be on a dedicated machine and multiple
    apps will be networked together.

    My dilemma is a colleague insists as much business logic as possible should
    reside in the SQL server rather than in Business tier in business objects.
    I am dead set against this for philosophical reasons, but I need some hard
    facts to plead my case.

    Does anyone have some solid, technical reasons to back up my claim that the
    database should simply provide data, not business logic (other than the obvious
    fact that it violates the layered architecture). I tried explaining it,
    but to no avail.

    Thanks for your input.

  2. #2
    Michael Gautier Guest

    Re: 3-Tier Architecture Help

    The short answer is that separating the tiers used to make sense but is
    starting be less necessary.

    If you are in a heterogenous environment (different backends, frontends and
    operating systems) the logical separation makes sense because environmental
    changes make the application less susceptible to total redevelopment.

    On a software engineering basis, the separation works because it bring about
    "intellectual control" over the application since it is easier to develop,
    troubleshoot, deploy and maintain an application in components.

    However, you have to look at "one thing" that is coming and that is Yukon or
    SQL Server for .NET. Why, oh why would they allow you to write stored
    procedures in a high level language, allow components to run in the process
    space of the database and give you the option to expose stored procedures as
    web services?

    The reason is performance, scalability and the fact that in corporations,
    the most important piece of a business system is the database. Sure,
    customers would like nice UIs and ROI on middleware, but what they want is
    "that data".

    From our standpoint as application developers, architects and engineers we
    usually design things according to principles, experience, ease and
    standards. But what takes precendence is performance, deployment and
    enterprise capabilities. In the past, that meant you could have COM+/MTS
    middle tier business components, but these had to be stateless. In the
    future, you could have 2 tiers; the data tier and the application teir. The
    data tier contains your state and scalable components while your application
    tier can be any number of web service, windows service facades or UI with
    thier own set of UI components. As long as the database is load balanced and
    failover setup, you have statefulness, performance, and with .NET components
    more maintianable software. For those components that have nothing to do
    with direct data access, those could still be in a middle tier.

    So to answer your question, you probably don't want business in the data
    tier today because SQL as a dialect is less maintainable than C# or VB and
    it will face competition from those languages as well as XQuery that could
    make it less relevant syntax.

    Tell your collegue that in a year or two (at most), that the .NET components
    written today may just be upgradeable to data tier components tomorrow.


    "Andy" <lorinandyb@msn.com> wrote in message
    news:3e83cdcc$1@tnews.web.devx.com...
    >
    > I am developing a medium/large scale stand-alone application which will

    contain
    > 3 logical tiers (Presentation/Business/Data), but only 1 physical tier

    (app
    > and SQL server running on same computer) for now. It is highly likely in
    > the near future the SQL server will be on a dedicated machine and multiple
    > apps will be networked together.
    >
    > My dilemma is a colleague insists as much business logic as possible

    should
    > reside in the SQL server rather than in Business tier in business objects.
    > I am dead set against this for philosophical reasons, but I need some

    hard
    > facts to plead my case.
    >
    > Does anyone have some solid, technical reasons to back up my claim that

    the
    > database should simply provide data, not business logic (other than the

    obvious
    > fact that it violates the layered architecture). I tried explaining it,
    > but to no avail.
    >
    > Thanks for your input.




  3. #3
    Andy Guest

    Re: 3-Tier Architecture Help


    Thanks for your reply, Michael. It was very enlightening. The primary business
    logic I am talking about is mathematical calculations (formulas), some of
    which are proprietary. What are your feelings on performing mathematical
    calculations such as this in the SQL process rather than retrieving the required
    data via SQL and performing the calculations in the app process? Keep in
    mind these calculations are not time-consuming such that a separate process
    is warranted.

  4. #4
    Michael Gautier Guest

    Re: 3-Tier Architecture Help

    Thank you.

    I think that future technology directions indicate that the specification of
    a business system's architecture is about options and requirements. In those
    areas of the application that rely heavily on data access and must perform
    very well, then they are candidates for running in the database's process
    space.

    In your case, if I was doing the same thing, I would probably do the
    mathematical calculations "outside" of the database since, "at this time",
    you will get a richer set of manipulations in a none-sql language. Your
    result-set from the database is either small enough to justify this type of
    deployment option (as they will be called) or if it is large, the results
    are structured in a way that they could possibly be extracted out of a
    recordset/dataset and manipulated directly (e.g. an array, properties or
    other lower overhead state mechanism).

    I would be tempted to do the calculations in the database if they were
    simple as I would not entrust the expressiveness of complex mathematical
    calculations to the Transact-SQL syntax. Again, as the technologies evolve
    towards the database, this will change, but today many of the common
    architectural standards are still justified.


    "Andy" <lorinandyb@msn.com> wrote in message
    news:3e849cd1$1@tnews.web.devx.com...
    >
    > Thanks for your reply, Michael. It was very enlightening. The primary

    business
    > logic I am talking about is mathematical calculations (formulas), some of
    > which are proprietary. What are your feelings on performing mathematical
    > calculations such as this in the SQL process rather than retrieving the

    required
    > data via SQL and performing the calculations in the app process? Keep in
    > mind these calculations are not time-consuming such that a separate

    process
    > is warranted.




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