Re: Data Access Objects?

Responding to Preuß..

I think you are mixing up DAOs and DTOs here - Data Transfer Objects
are the data packets, Data Access Objects contain the database (or
whatever) logic.


Doesn't that depend on which layer one is standing in?  That is, the
DTO has the data to transfer to the Data layer from the Business
layer and the DAO has the data to transfer to the Database layer from
the Data layer(?).  (It has been many, many moons since I've looked
at the CRUD/USER layered models, so I might well have screwed it up.)


As far as I know, the DTO is a simple data holder - only fields, and perhaps getters, no behaviour. A DAO, in contrast, contains the logic to extract the requested data from the data storage.

OK, I think I see the disconnect (though it is possible I am missing something more fundamental). In my world DAO's "behavior" is just a smart setter. It just initializes only its own knowledge attributes and, in doing so, applies no business rules or policies that are unique to the problem in hand. IOW, all it is doing is forming a message (e.g., a SQL query) to request its data.

An analogy would be a Matrix object that has complex algorithmic operations like "transform" and "invert" that affect lots of its data elements. But those operations are defined by a scope (mathematics) well beyond the problem in hand and they are self-contained. So in the problem context the Matrix is still just a dumb data holder and the methods, however complex their manipulations may be, are just setters for its knowledge responsibilities rather than unique behavior responsibilities.

[The distinction between knowledge and behavior tends to be more important to translationists because the code generator needs to unambiguously deal with scope for synchronous knowledge access if it implements concurrently. Life is much simpler if that is at the getter/setter method boundary. B-) (Technically the translation methodologies refer to knowledge accessors as "synchronous services" because the assumption is knowledge is accessed synchronously on an as-needed basis while they put all the functional behavior into actions in object state machines, whose access is inherently asynchronous.)]


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.

Relevant Pages

  • Re: Looking for a decent data access architecture to implement
    ... > application so that there is a clean separation between the data access ... > layer, the business layer and the GUI layer. ... > the actual database. ...
    (microsoft.public.dotnet.languages.csharp)
  • Looking for a decent data access architecture to implement
    ... application so that there is a clean separation between the data access ... layer, the business layer and the GUI layer. ... the actual database. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Simple OOP question
    ... table, what table you're updating, and what the database used is. ... it's not a good Data Layer method. ... just as the UI layer must know something about the business layer. ... conn = new SqlConnection; ...
    (microsoft.public.dotnet.framework.aspnet)
  • Typed dataset and datalayer
    ... business layer and a data layer. ... layer based on stored procedures in my SQL Server 2000 database. ... These methods are called in the business layer by means of XML Web Services. ...
    (microsoft.public.vstudio.development)
  • Re: "Business Objects" and the DAL
    ... layer talks to the layer next to it. ... business entity returned that up to the UI for binding to a grid. ... If a database table column names ... Each could be considered a "pattern", ...
    (microsoft.public.dotnet.framework.adonet)