Talk:Data access object
|WikiProject Computer science||(Rated Start-class)|
|The content of ORMLite was merged into Data access object. For the contribution history and old versions of the redirected page, please see ; for the discussion at that location, see its talk page.|
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."
Sorry, persistencifier is not a word.
How i can call a procedure created in the module section of Access 97 from Visual Basic by using DAO?
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 18.104.22.168 (talk) 11:12, 6 September 2007 (UTC)
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)
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 22.214.171.124 (talk) 14:36, 6 October 2008 (UTC)
RE: proposed merge with ActiveRecord
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 and DataMapper (his name for DAO). —Preceding unsigned comment added by 126.96.36.199 (talk) 01:28, 5 June 2010 (UTC)
- 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. 188.8.131.52 (talk) 18:43, 16 February 2011 (UTC)
- 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)
- 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)