Results 1 to 10 of 10
  1. #1
    Join Date
    Feb 2004
    Posts
    2

    Unanswered: Advice on Application Architecture

    We are writing a VB/Oracle application. There has been some discussion on where the business rules should reside (ie., in VB or Oracle). One point of view is business rules will be in classes in VB and calls will be made to Oracle for data manipulation. The other point of view is calls will be made to Oracle where the validation and data manipulation will occur and VB will get the result.

    Needed some advice on what is practised in industry? What are some experiences people have had? Pros and Cons?

    Thank You!

  2. #2
    Join Date
    Sep 2002
    Location
    UK
    Posts
    5,171
    Provided Answers: 1
    What will your business rules be doing? Probably accessing the database (check whether an X exists, etc.) Which is more suited to accessing the database: VB or Oracle itself? Er...

    To me, it's a no-brainer (i.e. the answer is Oracle). But a VB-head will probably disagree. Ask them to explain why, and then post their responses here.

  3. #3
    Join Date
    Jun 2004
    Posts
    34
    If you follow three-tier application architecture(Presentation/Business logic/Data Access), the "best practice" is that you should put your business logic in the business logic tier, In Oracle, it should only have basic CRUD(Create/Read/Update/Delete) operations. On the other word, move business logic out off your Oracle packages/stored procedures, and put it in VB.

    Why?

    If you design your applicatio this way, it will make it easier to maintain and to enhance.

    If you follow client/server architecture, sure you can put your business logic in Oracle package/stored procedrues.

    Which architecture you will use, it all depend on what kind of application you will develop, is this web/distributed application, or stand alone windows application? How many users? etc. These are questions we will ask before we design our application.

  4. #4
    Join Date
    Sep 2002
    Location
    UK
    Posts
    5,171
    Provided Answers: 1
    What the heck has 3-tier archictecture got to do with it? Reducing Oracle to handling mere "CRUD" is as bad as it sounds. Why not this "3-tier" architecture?
    1) Presentation - VB or whatever
    2) Business Logic - Oracle packages called from presentation layer
    3) Data Access - Oracle SQL invoked from packages

    Please explain how putting business logic into VB makes maintenance easier!

  5. #5
    Join Date
    Oct 2004
    Posts
    145
    I agree with putting much logic/manipulation in the database as possible. Database servers are usually more powerful and process much faster.

    Unless the developers are thinking of making the application independent of the backend, there is NO reason not to utilize the full capacities of the database.

    If you are to use database specially a relational database for purpose of CRUD why not use a flat file system. The flat file system maybe faster for you perform simple CRUD.

    Putting the logic on the backend will reduce network traffic, etc and will be much easier to tune for performance.

  6. #6
    Join Date
    Jun 2004
    Posts
    34
    There is no big differrence if your application logic is simple, but if your application begin to grow, you got maintenance problem. Here is an example, I want all customers who have bought ProductX in the past three months, I have to go back to Oracle and add a stored procedure to handle this. Now If I want all customers who live in New York, another procedure, right? When you have compex domain logic and you have a large database, you will add more and more procedrues, right?

    Now if you move your business logic into application, most time, you can apply your business rules in the objects in one network round trip without add more procedures by applying some object-oriented design patterns, it will also reduce your network traffic and reduce burden in your Oracle server.

    Also conside this, if for some reason, you decide to use SQL Server or DB2 instead of Oracle, it will be much easier to migrate your code if your business logic is in VB instead of in Oracle.

    Just my 2 cents...

    Li Xin
    Last edited by r937; 03-23-08 at 00:46.

  7. #7
    Join Date
    Jun 2004
    Location
    Liverpool, NY USA
    Posts
    2,509
    I also agree, but your business rules in the database That way, no one can violate them no matter how they get to the database. To implement relationships and validation only in the application code is NOT a good idea.
    Bill
    You do not need a parachute to skydive. You only need a parachute to skydive twice.

  8. #8
    Join Date
    Sep 2002
    Location
    UK
    Posts
    5,171
    Provided Answers: 1
    Quote Originally Posted by latticesoft
    There is no big differrence if your application logic is simple, but if your application begin to grow, you got maintenance problem. Here is an example, I want all customers who have bought ProductX in the past three months, I have to go back to Oracle and add a stored procedure to handle this. Now If I want all customers who live in New York, another procedure, right? When you have compex domain logic and you have a large database, you will add more and more procedrues, right?
    Ah, you are talking about reports! I have no objection to writing reports in VB. When I say all business logic should be in the database, I mean business rules: integrity, transactions etc.

  9. #9
    Join Date
    Sep 2004
    Location
    London, UK
    Posts
    565
    On the other word, move business logic out off your Oracle packages/stored procedures, and put it in VB.

    Why?

    If you design your application this way, it will make it easier to maintain and to enhance.

    If you follow client/server architecture, sure you can put your business logic in Oracle package/stored procedures.
    Right, I'm confused. How is a VB application not client/server?

    Moving data processing away from the data may be convenient for a client-side developer, but I suspect the approach will not look so good when you need to add a new client app - batch, web, Java, wireless or whatever.

    Developers only make the client app independent of the database vendor if they are planning to market a product on multiple platforms. It does not benefit the end user.

  10. #10
    Join Date
    Nov 2002
    Location
    Desk, slightly south of keyboard
    Posts
    697
    Hi,

    Keep rules as close to the thing which is bieng ruled as possible. If your rules require that a pixel at 100,230 be green then that's going to have to be done in your client app.

    If your rules require that a user press the 'any key' before commiting, that's got to be done in your client app.

    If your rules require that a column be constrained by another, use the database that stores the column. It's what it was designed to do.

    Reliable, maintainable, clean, efficient.

    Whoops, apologies to all, I forgot that reliable and efficient isn't fashionable.

    Hth
    Bill
    Please don't email me directly with questions. I've probably just got home from the pub and cannot guarantee the sanity of my answers. In fact, I can't believe I actually made it home.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •