Condividi tramite

Is anyone really buying this?

  • Articolo

A data layer is all about abstracting the explicit boundary between the application/ domain model and the persistence datasource.

Although this boundary can never be totally transparent, the data layer does its best to expose the persistence data in a way which can be easily and suitably utilized by domain model. A simple example is accessing a file through a reader interface which abstracts the user from the underlying details of reading a file from disk. A more complex example is accessing relational databases which abstracts the user from the underlying storage mechanism and enforces a number of domain specific rules in an effort to keep shared data consistent.

This requirement is totally orthogonal to whether SOA or traditional 3 tier architectures are being utilized. I am continually amazed how various people in the industry are suggested that SOA means the end of objects and the data layer. To me, a vast majority of services are going to be written in OO languages and still need to persist data. I suppose one could say that data persistence will just be another service (a very special service at that) – but this is just adding a façade to the same requirements and the same code. In fact, I would guess that a significant amount of ASP.net code is doing this precise task on multitudes of production systems today.

Comments

  • Anonymous
    January 06, 2005
    I'm not buying what you're selling. In fact, I think you've expressed what is the most pernicious commonly held idea in software architecture. This notion of persistence is simply nonsense. Applications put information into a relational database for a purpose that has nothing to do with saving an object's state. If we were just interested in "persistence" then we would merely serialize our objects to flat files. Moving information between your application's processing view and a relational database represents a transformation that is central to the nature of your application. Making that transformation "transparent" means relinquishing your control and understanding of a critical part of your application design. Thinking of that transformation as "persistence" leads to badly designed object models and relational structures. Instead of ORM tools, we need tools that help us focus on the design of the transformation.
  • Anonymous
    January 06, 2005
    Uh no...some people have several books and a whole lot of time invested in their view of the world, which unfortunately isn't in sync with SOA.

    <b>I'm not buying it!</b>
  • Anonymous
    January 06, 2005
    SOA is a archetecture strategy and not a programming tactic. But hey, it could also bring world peace.

    http://dictionary.reference.com/search?r=67&q=strategy

    http://dictionary.reference.com/search?r=67&q=tactic

    I think the Indigo team is doing some interesting work with the concept of DataContracts. Converting objects to/from XML. Keeping the DataContract seperate from objects so that multiple objects can subscribe to the same XML data.

    Maybe O/R mapping is not the way ultimately. It does't ask the DB to change. The suppport for XML in SQL2005 is really interesting, especially that you can store whole XML documents but you can XPath (or XQuery or Xsomthing) against it to return relational values. (Please correct me if I'm wrong.)


    I don't think MS can approach the whole SQL/XML persistance thing as Bill mentioned until they get as clear an understanding as for O/R/XML relationships as the Indigo team did for O/XML relationships.


    >> In fact, I would guess that a significant
    >> amount of ASP.net code is doing this
    >> precise task on multitudes of production
    >> systems today.

    Yes. It's get mind numbing after a while. It becomes really frustrating. The DataSet is good, but it's a very heavy object - but powerful. And there's always the debate as to use objects or datasets. They each have their advantages and disadvantages.

    (BTW - it would be really great if on the DataSet one could reject changes to a table by column or reject changes by rowstate.)

    Sorry for rambling so long.

    Wish we could have had some type of O/R famework in '05.

  • Anonymous
    January 07, 2005
    Hello Conrad,

    We would welcome any comments or suggestions you'd like to make about this article. Just go to our site and click the "Post Reply" button. Rocky floated this article as a means of getting people talking about the DAL in new ways. It's not meant to be an description of how things should be done, just another possible way of thinking about it.

    Paul Ballard, Editor
    TheServerSide.NET
  • Anonymous
    January 07, 2005
    See this for Rocky Lhotka's own comments on the article: http://www.lhotka.net/WeBlog/PermaLink.aspx?guid=333d2cce-8dfc-4f49-9065-8d75451fb90b

  • Anonymous
    January 07, 2005
    I don't think there's any good reason not to use OO/ORM techniques behind service boundaries, especially given the immaturity of WS transaction standards/available implementations. Certainly good transaction support is a necessity for interacting with a database.

    That way, you get the best of both worlds. A nice defined interface with the external world (SOA) and a good Domain model which is decoupled from your db schema for a clean implementation.
  • Anonymous
    January 09, 2005
    Yes, I buy it. To be more precise, I've bought it, yet. We made some SOA apps, and each and every had a DataLayer.
    SOA it's about architecture, and it's about pieces loosely coupled. Some one must actually do the hard work and mess with data, maybe it's a Service, maybe not. But DL will be there to help.
  • Anonymous
    June 16, 2009
    PingBack from http://topalternativedating.info/story.php?id=2127