Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. Other Discussions
  3. IT & Infrastructure
  4. data access tier options

data access tier options

Scheduled Pinned Locked Moved IT & Infrastructure
xmldatabaseoraclewcfcom
5 Posts 3 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • L Offline
    L Offline
    lejuan5150
    wrote on last edited by
    #1

    hi there ... i am new to these forums (this is my first post) ... i am hoping you guys could help me make an architectural decision on how to implement a data access tier ... here is the situation: - we have a large oracle database (thousands of tables) - we want to isolate applications from database changes - applications can access the data access tier via soap or dcom our team came up with two options diagrammed below ... essentially, option 1 is creating a representation of the database in xml using oracle stored procedures, with a simple com+ component for client access ... option 2 is creating an object hierarchy in com+ that represents the database ... the hierarchy can be accessed directly or be converted to xml. any opinions on which option is better? thanks, john

    L R I 3 Replies Last reply
    0
    • L lejuan5150

      hi there ... i am new to these forums (this is my first post) ... i am hoping you guys could help me make an architectural decision on how to implement a data access tier ... here is the situation: - we have a large oracle database (thousands of tables) - we want to isolate applications from database changes - applications can access the data access tier via soap or dcom our team came up with two options diagrammed below ... essentially, option 1 is creating a representation of the database in xml using oracle stored procedures, with a simple com+ component for client access ... option 2 is creating an object hierarchy in com+ that represents the database ... the hierarchy can be accessed directly or be converted to xml. any opinions on which option is better? thanks, john

      L Offline
      L Offline
      lejuan5150
      wrote on last edited by
      #2

      ooops ... the image didn't show up ... here is a link ... http://www.lejuan5150.com/lejuan5150/media/dataaccesstier.jpg[^]

      1 Reply Last reply
      0
      • L lejuan5150

        hi there ... i am new to these forums (this is my first post) ... i am hoping you guys could help me make an architectural decision on how to implement a data access tier ... here is the situation: - we have a large oracle database (thousands of tables) - we want to isolate applications from database changes - applications can access the data access tier via soap or dcom our team came up with two options diagrammed below ... essentially, option 1 is creating a representation of the database in xml using oracle stored procedures, with a simple com+ component for client access ... option 2 is creating an object hierarchy in com+ that represents the database ... the hierarchy can be accessed directly or be converted to xml. any opinions on which option is better? thanks, john

        R Offline
        R Offline
        Ray Cassick
        wrote on last edited by
        #3

        How about using a web service between teh stored procs and the client to take care of reading data and translating to XML...

        1 Reply Last reply
        0
        • L lejuan5150

          hi there ... i am new to these forums (this is my first post) ... i am hoping you guys could help me make an architectural decision on how to implement a data access tier ... here is the situation: - we have a large oracle database (thousands of tables) - we want to isolate applications from database changes - applications can access the data access tier via soap or dcom our team came up with two options diagrammed below ... essentially, option 1 is creating a representation of the database in xml using oracle stored procedures, with a simple com+ component for client access ... option 2 is creating an object hierarchy in com+ that represents the database ... the hierarchy can be accessed directly or be converted to xml. any opinions on which option is better? thanks, john

          I Offline
          I Offline
          ian mariano
          wrote on last edited by
          #4

          Architecturally, here's a good reference: Designing Data Tier Components and Passing Data Through Tiers[^]. It is of course .NET. -- ian


          "The greatest danger to humanity is humanity without an open mind."
          - Ian Mariano
          http://www.ian-space.com/

          L 1 Reply Last reply
          0
          • I ian mariano

            Architecturally, here's a good reference: Designing Data Tier Components and Passing Data Through Tiers[^]. It is of course .NET. -- ian


            "The greatest danger to humanity is humanity without an open mind."
            - Ian Mariano
            http://www.ian-space.com/

            L Offline
            L Offline
            lejuan5150
            wrote on last edited by
            #5

            thanks ... excellent article

            1 Reply Last reply
            0
            Reply
            • Reply as topic
            Log in to reply
            • Oldest to Newest
            • Newest to Oldest
            • Most Votes


            • Login

            • Don't have an account? Register

            • Login or register to search.
            • First post
              Last post
            0
            • Categories
            • Recent
            • Tags
            • Popular
            • World
            • Users
            • Groups