interfacing with data layer

Discussion in 'ASP .Net' started by headware, May 14, 2004.

  1. headware

    headware Guest

    I'm relatively new to ASP.NET and ADO.NET, but I have a basic design
    question regarding the use of web services and APS.NET applications.
    Right now we have an application that uses web services to access the
    database layer. However, the code works in a pretty cumbersome and
    ungeneric way. Basically every query, update, and insert has its own
    [WebMethod] function. So you see a lot of functions like

    webService.InsertCustomer(name, age, phone);
    or
    DataSet custDS = webService.GetAllCustomers();
    or
    webService.UpdateCustomer(custId, name, age, phone);

    I have my doubts about whether this is the best way to be interfacing
    with the data layer. Couldn't you store the customer currently being
    worked on (assuming you have a page in which you can work on the data
    for a single customer at a time) in a DataSet stored in the Session
    object and send that DataSet back to the data later so the DataAdapter
    can call the Update() method on it? Unless I'm missing something, that
    should allow you to have only one web service function for inserting,
    deleting, and updating any table in the database. For example, you
    could update the database like this

    [WebMethod]
    public void UpdateDatabase(DataSet ds)
    {
    OleDbConnection connection = new OleDbConnection("");
    OleDbDataAdapter adapter = new OleDbDataAdapter("SELECT * FROM " +
    ds.Tables[0].TableName, connection);
    adapter.Update(ds);
    }

    As long as the DataSet rows have the proper rowstate values, this one
    function should do all your inserting, updating, and deleting for you,
    right?

    Of course, you'd have to be careful about storing large DataSets in
    the Session object for the sake of scalability. In our particular
    application, there would never be all that many users logged on at any
    given point so I don't think that should be an issue.

    What I'm really getting at here is that I would like
    ideas/experience/articles/books about how people interface with the
    data layer in ASP.NET applications.

    Thanks,
    Dave
     
    headware, May 14, 2004
    #1
    1. Advertising

  2. Let's look at the purpose of web services, whether ASMX or Remoting, which
    is a transport mechanism. This mechanism can sit between the Business layer
    and the data layer or the data layer and the UI. Ultimately, the core of the
    data layer is more generic, like the Microsoft Data Access Application
    Block. There are times you will have more specific data elements on the data
    layer, like strongly typed DataSet definitions with their data access
    methods (which use the generic data tier) and other times, the business
    rules will be more of a driver (indicating the sproc used to access data,
    for example).

    In your model, you can have the web method stay as is, but add something
    more generic on another data tier. The Data Access Application Block is not
    a bad choice, as it is free and the code is already written for you. There
    is an error in the FillDataSet() method where the table mapping names are
    linked to the generic names created when the DataSet is filled, but it is
    not too hard to edit.

    Now, to where the web service should be.

    If you have an "app server" that also hosts your data access code, you will
    have web services as the transport between web server (UI) and app (business
    layer). If you are dealing with web server, app server and data server, you
    may end up with web services at both spots, although the Remoting type
    perform better. NOTE that it is unusual to have two web services layers in
    your app model. More common, you will see database server with business
    rules and data on the same server, as filtered data (data that has passed
    through some form of business rules component(s)) is more common, esp. since
    you often see web services used for Extranet situations.

    Another option is setting up your assemblies to go inside COM+ and
    distributing your application that way.

    I realize this is more theory than anything else, but I hope it gives you
    some ideas.

    --
    Gregory A. Beamer
    MVP; MCP: +I, SE, SD, DBA

    *************************************************
    Think outside the box!
    *************************************************
    "headware" <> wrote in message
    news:...
    > I'm relatively new to ASP.NET and ADO.NET, but I have a basic design
    > question regarding the use of web services and APS.NET applications.
    > Right now we have an application that uses web services to access the
    > database layer. However, the code works in a pretty cumbersome and
    > ungeneric way. Basically every query, update, and insert has its own
    > [WebMethod] function. So you see a lot of functions like
    >
    > webService.InsertCustomer(name, age, phone);
    > or
    > DataSet custDS = webService.GetAllCustomers();
    > or
    > webService.UpdateCustomer(custId, name, age, phone);
    >
    > I have my doubts about whether this is the best way to be interfacing
    > with the data layer. Couldn't you store the customer currently being
    > worked on (assuming you have a page in which you can work on the data
    > for a single customer at a time) in a DataSet stored in the Session
    > object and send that DataSet back to the data later so the DataAdapter
    > can call the Update() method on it? Unless I'm missing something, that
    > should allow you to have only one web service function for inserting,
    > deleting, and updating any table in the database. For example, you
    > could update the database like this
    >
    > [WebMethod]
    > public void UpdateDatabase(DataSet ds)
    > {
    > OleDbConnection connection = new OleDbConnection("");
    > OleDbDataAdapter adapter = new OleDbDataAdapter("SELECT * FROM " +
    > ds.Tables[0].TableName, connection);
    > adapter.Update(ds);
    > }
    >
    > As long as the DataSet rows have the proper rowstate values, this one
    > function should do all your inserting, updating, and deleting for you,
    > right?
    >
    > Of course, you'd have to be careful about storing large DataSets in
    > the Session object for the sake of scalability. In our particular
    > application, there would never be all that many users logged on at any
    > given point so I don't think that should be an issue.
    >
    > What I'm really getting at here is that I would like
    > ideas/experience/articles/books about how people interface with the
    > data layer in ASP.NET applications.
    >
    > Thanks,
    > Dave
     
    Cowboy \(Gregory A. Beamer\), May 14, 2004
    #2
    1. Advertising

  3. headware

    headware Guest

    Thanks for the response. The more I think about the situation the more
    I think that the correct solution is to build a business layer between
    the UI and the database. Doing that would make the issues I brought up
    in the first post mostly moot.

    I checked out the ASP.NET Alliance start kits (found at
    http://www.asp.net/Default.aspx?tabindex=9&tabid=47). The two that I
    have downloaded and looked at are set up as 3-tiered systems with
    ASP.NET as the UI, a set of classes to perform the business logic, and
    SQL Server Stored Procs as the data access tier. Seems like a pretty
    good separation except for the fact that the business tier is
    dependent on ADO.NET since it instantiates classes like SqlDataAdapter
    to call the Stored Procs. The UI layer is also dependent on ADO.NET
    since it uses the DataSets and DataReaders the business layer returns.
    Is that considered good practice? I realize that it would probably be
    difficult to totally separate the technologies used from the different
    layers of the application. I suppose you'd have to come up with your
    own classes for sharing the data between layers. Is that done often?

    Dave

    "Cowboy \(Gregory A. Beamer\)" <> wrote in message news:<#>...
    > Let's look at the purpose of web services, whether ASMX or Remoting, which
    > is a transport mechanism. This mechanism can sit between the Business layer
    > and the data layer or the data layer and the UI. Ultimately, the core of the
    > data layer is more generic, like the Microsoft Data Access Application
    > Block. There are times you will have more specific data elements on the data
    > layer, like strongly typed DataSet definitions with their data access
    > methods (which use the generic data tier) and other times, the business
    > rules will be more of a driver (indicating the sproc used to access data,
    > for example).
    >
    > In your model, you can have the web method stay as is, but add something
    > more generic on another data tier. The Data Access Application Block is not
    > a bad choice, as it is free and the code is already written for you. There
    > is an error in the FillDataSet() method where the table mapping names are
    > linked to the generic names created when the DataSet is filled, but it is
    > not too hard to edit.
    >
    > Now, to where the web service should be.
    >
    > If you have an "app server" that also hosts your data access code, you will
    > have web services as the transport between web server (UI) and app (business
    > layer). If you are dealing with web server, app server and data server, you
    > may end up with web services at both spots, although the Remoting type
    > perform better. NOTE that it is unusual to have two web services layers in
    > your app model. More common, you will see database server with business
    > rules and data on the same server, as filtered data (data that has passed
    > through some form of business rules component(s)) is more common, esp. since
    > you often see web services used for Extranet situations.
    >
    > Another option is setting up your assemblies to go inside COM+ and
    > distributing your application that way.
    >
    > I realize this is more theory than anything else, but I hope it gives you
    > some ideas.
    >
    > --
    > Gregory A. Beamer
    > MVP; MCP: +I, SE, SD, DBA
    >
    > *************************************************
    > Think outside the box!
    > *************************************************
    > "headware" <> wrote in message
    > news:...
    > > I'm relatively new to ASP.NET and ADO.NET, but I have a basic design
    > > question regarding the use of web services and APS.NET applications.
    > > Right now we have an application that uses web services to access the
    > > database layer. However, the code works in a pretty cumbersome and
    > > ungeneric way. Basically every query, update, and insert has its own
    > > [WebMethod] function. So you see a lot of functions like
    > >
    > > webService.InsertCustomer(name, age, phone);
    > > or
    > > DataSet custDS = webService.GetAllCustomers();
    > > or
    > > webService.UpdateCustomer(custId, name, age, phone);
    > >
    > > I have my doubts about whether this is the best way to be interfacing
    > > with the data layer. Couldn't you store the customer currently being
    > > worked on (assuming you have a page in which you can work on the data
    > > for a single customer at a time) in a DataSet stored in the Session
    > > object and send that DataSet back to the data later so the DataAdapter
    > > can call the Update() method on it? Unless I'm missing something, that
    > > should allow you to have only one web service function for inserting,
    > > deleting, and updating any table in the database. For example, you
    > > could update the database like this
    > >
    > > [WebMethod]
    > > public void UpdateDatabase(DataSet ds)
    > > {
    > > OleDbConnection connection = new OleDbConnection("");
    > > OleDbDataAdapter adapter = new OleDbDataAdapter("SELECT * FROM " +
    > > ds.Tables[0].TableName, connection);
    > > adapter.Update(ds);
    > > }
    > >
    > > As long as the DataSet rows have the proper rowstate values, this one
    > > function should do all your inserting, updating, and deleting for you,
    > > right?
    > >
    > > Of course, you'd have to be careful about storing large DataSets in
    > > the Session object for the sake of scalability. In our particular
    > > application, there would never be all that many users logged on at any
    > > given point so I don't think that should be an issue.
    > >
    > > What I'm really getting at here is that I would like
    > > ideas/experience/articles/books about how people interface with the
    > > data layer in ASP.NET applications.
    > >
    > > Thanks,
    > > Dave
     
    headware, May 18, 2004
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. et
    Replies:
    2
    Views:
    1,943
  2. Wolfgang
    Replies:
    1
    Views:
    1,131
  3. java-john
    Replies:
    0
    Views:
    543
    java-john
    Mar 23, 2006
  4. Ily
    Replies:
    2
    Views:
    356
    Robert Haken [MVP]
    Oct 13, 2006
  5. Dhananjay
    Replies:
    1
    Views:
    1,166
    sloan
    Dec 18, 2006
Loading...

Share This Page