Leo said:
Ah...I should clarify. When I mention DAO, it's not DAO as in the
alternative for ADO back in the day. DAO is a design pattern. I think
it is a GOF design pattern or at least a branch off of that. This
might be why MS refers to it as DALC (if that's the case), in order to
prevent confusion for MS developers.
The J2EE DAO (Data Access Object) pattern is, according to
Fowler's "Patterns of Enterprise Application Architecture",
equivalent to a "Table Data Gateway" or "Row Data Gateway"
(no, that is not a Microsoft term).
http://www.martinfowler.com/eaaCatalog/tableDataGateway.html
http://www.martinfowler.com/eaaCatalog/rowDataGateway.html
In Microsoft technology a "Table Data Gateway" would
encapsulate the logic, SQL and/or stored procedure access to
create, retrieve, update and delete result sets from the a
single table in the database and place them inside an
ADO.NET DataSet (possibly strongly typed). Note that the
DataSet may hold more than one table but each table would be
handled by a separate gateway.
Gateways tend to be used with applications that use Table
Modules.
http://www.martinfowler.com/eaaCatalog/tableModule.html
An ADO.NET DataSet can be used as a Table Module - but it
can in fact contain multiple DataTables.
More sophisticated applications would tend to use Domain
Objects
http://www.martinfowler.com/eaaCatalog/domainModel.html
which tend to be managed by Data Mappers
http://www.martinfowler.com/eaaCatalog/dataMapper.html
In a layered architecture the Active Record tends to be
avoided as it blurs the distinction between Data Access
Component and Business Component.
http://www.martinfowler.com/eaaCatalog/activeRecord.html
So Data Access Logic Components could contain gateways, or
data mappers or both. If you were using SQL-Server,
references to System.Data.SqlClient should be limited to
this layer. Ideally the same should be true for System.Data
(ADO.NET) however most of the time this will not be the case
- mainly because of the data state tracking and integration
with some GUI components.
For some patterns in the .NET context see:
Enterprise Solution Patterns Using Microsoft .NET
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpatterns/html/esp.asp
http://www.microsoft.com/downloads/...8E-ABFC-484F-A076-CF99B3485754&displaylang=en
Data Access Logic Components usually refers to all
components the reside in the (architectural) 'Data Access
Layer':
- UI Components
- UI Process Components
- Business Service Interfaces
- Business Workflow | Components | Entities
- Data Access Logic Components | Service Agents
- Data Sources | Services
see
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/distapp.asp
Ideally only data transfer objects (for simple applications)
or domain objects (for sophisticated applications) would
travel to and from the business layer.
In reality ADO.NET DataSets (due to their integration with
GUI components such as the DataGrid) will often travel all
the way to the presentation layer ultimately exposing the
relational data model to every layer of the application.
Application Architecture for .NET: Designing Applications
and Services
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/distapp.asp
http://www.microsoft.com/downloads/...09-7AE3-4942-B466-CC778A3BAB34&displaylang=en
'Any fool can write code that a computer can understand.
Good programmers write code that humans can understand.'
Martin Fowler,
'Refactoring: improving the design of existing code', p.15
