471,344 Members | 1,516 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,344 software developers and data experts.

DALC vs DAO

Leo
I'll make it brief: are DALC (Data Access Layer Components) and DAO
(Data Access Objects) the same thing? They appear to be from what I've
read on MSDN. I'm quite familiar with the DAO pattern from my J2EE
background and was trying to figure out if this is just Microsoft just
giving a new name to an old pattern or if it's something I should be
looking into instead of DAO.

Thanks,
Leo

Jul 21 '05 #1
3 8192
I do not know the exactly meaning when you are talking DAO in J2EE. It may
has the same or similar context there as DALC. But in MS world, DAO has
specific meaning and is not the same or similar as DALC. DAO is, like other
MS data access technology, such as ODBC, OLEDB, ADO, ADO.NET, used by
application developer t build their DALC on top it. Since you are asking the
question in a .NET NG, just remind you .NET does not use DAO, it uses
ADO.NET instead, it can communicate with DAO through Interop, though.

"Leo" <le******@fmr.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
I'll make it brief: are DALC (Data Access Layer Components) and DAO
(Data Access Objects) the same thing? They appear to be from what I've
read on MSDN. I'm quite familiar with the DAO pattern from my J2EE
background and was trying to figure out if this is just Microsoft just
giving a new name to an old pattern or if it's something I should be
looking into instead of DAO.

Thanks,
Leo

Jul 21 '05 #2
Leo
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.

Jul 21 '05 #3
"Leo" <le******@fmr.com> wrote:
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/eaaCatal...taGateway.html
http://www.martinfowler.com/eaaCatal...taGateway.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/eaaCatal...iveRecord.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/de...s/html/esp.asp
http://www.microsoft.com/downloads/d...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/de...ml/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/de...ml/distapp.asp
http://www.microsoft.com/downloads/d...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
Jul 21 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by jacobryce | last post: by
reply views Thread by David Veeneman | last post: by
reply views Thread by Marcel Cugini | last post: by
4 posts views Thread by Alex Stevens | last post: by
3 posts views Thread by Leo | last post: by
reply views Thread by Ronak mishra | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.