minimum business layer in a high concurrency project? RRS feed

  • Question

  • I don't understand what we are doing in my current project.

    We are making the business layer slimmer and increasing pl/sql. My project is a high concurrency one, with lot of users using it. They say that the systems worked bad with a big COM+ layer and now works better.

    I think the only way that this idea is correct is if the thick COM+ layer was wrong. In general, and perhaps always, making a business layer in a big project should be the right direction.

    At the end the bottleneck is the DB, and complex pl/sql will make it work much more, isn't it?

    Monday, March 13, 2006 9:11 AM

All replies

  • Hi,

    you will find the answer here ... http://www.codeproject.com/gen/design/DudeWheresMyBusinessLogic.asp.

    Happy Reading !


    Monday, March 13, 2006 10:10 AM
  • I read it before, it is an excelent article in an excelent site.

    It is a pitty that in Spain we don't have culture of n-tiers app, soa... we are in the 80s, or even the 70s.

    Well, i just have to wait the narrow minded bosses to retire, just 20 or 30 years :)

    Monday, March 13, 2006 10:24 AM
  • COM+ in the pre .NET era was relatively complicated to get right which resulted in a lot of bad COM+ implementations. - so I guess that may be where this notion originated from

    There are several reasons why you don't want business logic to reside on the DB

    for one it is more complicated to maintain it , plus there are a lot of business related functions that are handled better and easier to develop using OO languages.

    The other reason has to do with costs - It is usually more cost effective scaling out rather then scaling up (adding cheap servers vs. buying an expensive server) . Scaling out a database is a very complicated task (e.g. designing a federated database ) and thus it is easier to scale out business logic

    other reasons for multi-tiring is operational costs, easier to secure, to solve performance problems  etc.


    Monday, March 13, 2006 9:19 PM