Talk:Data access object

This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Computer scienceWikipedia:WikiProject Computer scienceTemplate:WikiProject Computer scienceComputer science articles

???

This article has not yet received a rating on the project's importance scale.

Things you can help WikiProject Computer science with:

Here are some tasks awaiting attention:

Article requests :
- Requested articles/Applied arts and sciences/Computer science, computing, and Internet
Cleanup :
- Computer science articles needing attention
- Computer science articles needing expert attention
Copyedit :
- Computing
Expand :
- Computer science
Infobox :
- Computer science articles without infoboxes
Maintain :
- Timeline of computing 2020–present
Photo :
- Find pictures for the biographies of computer scientists (see List of computer scientists)
- Computing articles needing images
Stubs :
- Computer science stubs
Unreferenced :
- WikiProject Computer science/Unreferenced BLPs
Project-related :
- Tag all relevant articles in Category:Computer science and sub-categories with {{WikiProject Computer science}}

Razor[edit]

I've read through the Occam's razor page and I can't find any discussion on how it's typically used in the field of applied science, let alone software development. I think its use in this article is invalid and confusing and should be removed. This design pattern should be used because of pragmatic reasons in order to abstract as much as possible the interaction between complex systems. This can be a valid reason to add an extra layer and there's no reason to shed doubt over this requirement if it's not constructive."

persistencifier?[edit]

Sorry, persistencifier is not a word.

Doubt[edit]

How i can call a procedure created in the module section of Access 97 from Visual Basic by using DAO?

Disadvantages[edit]

The section was deleted because it was really about any kind of database abstraction, because the asserted complexity is actually a matter of taste, and because the asserted runtime abstraction penalty is simply not plausible: a DAO transforms data between objects and single columns, which is unavoidable, and executes the same queries as any other abstraction or non-abstraction, without adding excess baggage other than function calls and object references. —Preceding unsigned comment added by 81.208.61.202 (talk) 11:12, 6 September 2007 (UTC)[reply]

Right now the disadvantages include the same argument three times, frased slighty different. —Preceding unsigned comment added by 83.188.194.210 (talk) 20:36, 6 February 2009 (UTC)[reply]

The one disadvantage currently listed ("A certain amount of skill is required to implement a DAO design pattern or use a DAO product.") is a disadvantage to literally anything. If this level of generality is acceptable, every single page on Wikipedia about any option of any sort should this disadvantage. Since every choice in every field has this disadvantage, it's actually not a disadvantage anyway. How would choosing to use a DAO hinder your progress ("dis-advance" you) anymore than anything else? Don (talk) 20:48, 26 October 2010 (UTC)[reply]

Pending issues[edit]

Would be interresting to locate more DAO frameworks since writing code for such a clear design pattern as DAO is reinventing the wheel each time —Preceding unsigned comment added by 84.76.66.212 (talk) 14:36, 6 October 2008 (UTC)[reply]

RE: proposed merge with ActiveRecord[edit]

The DAO pattern and the ActiveRecord pattern are quite distinct patterns for data access. The ActiveRecord pattern is characterized by a domain model that "knows" it is persistent - each entity class has a Save() method on it. In contrast, the entire point of the DAO pattern is that the entities do not know that they are persistent objects. This maintains a stricter separation of concerns. Each pattern has its advantages and disadvantages, but to merge the two articles, and lose the distinction between the two patterns, makes no sense. Compare Martin Fowler's articles on ActiveRecord^[1] and DataMapper^[2] (his name for DAO). —Preceding unsigned comment added by 206.188.66.141 (talk) 01:28, 5 June 2010 (UTC)[reply]

A merge would be inappropriate, as the DAO design pattern is a further abstraction above Hibernate or other databases. It makes it possible to remove the database completely to substitute with a text file data system, say. 217.116.183.201 (talk) 18:43, 16 February 2011 (UTC)[reply]

A merge is inappropriate, as a DAO is not necessarily an abstraction for a relational database. It may be an interface to a normal text file, say. Sae1962 (talk) 10:35, 3 May 2011 (UTC)[reply]

I also agree a merge doesn't make sense. The pattern used in the software development industry is called "Data Access Object." If this article were named anything else, I wouldn't have found it. When can we remove the pending merge notice? Kshannon (talk) 13:20, 22 July 2011 (UTC)[reply]

Oppose merge:* they're very, very different beasts. David (talk) 19:04, 29 September 2011 (UTC)[reply]

Given that everyone has opposed since February, I'm going to edit the main article to remove the notice. David (talk) 19:04, 29 September 2011 (UTC)[reply]

References

Traditionally associated with Java EE applications[edit]

Is it still valid to say traditionally associated with Java EE applications? See c# - Is the DAO Pattern Widely Used in .NET? - Stack Overflow. Sam Tomato (talk) 19:45, 23 April 2020 (UTC)[reply]

[1] ttp://martinfowler.com/eaaCatalog/activeRecord.html

[2] ttp://martinfowler.com/eaaCatalog/dataMapper.html

[1]

[2]