From e8155d4abba61db094defcf1c6dc0c42d7f4f26c Mon Sep 17 00:00:00 2001 From: Kerry Ivan Kurian Date: Sun, 13 Oct 2013 13:13:16 -0600 Subject: [PATCH 1/4] update teh readme --- README | 84 +++++++++++++++++++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 71 insertions(+), 13 deletions(-) diff --git a/README b/README index 6d72aa7..cc0ca30 100644 --- a/README +++ b/README @@ -38,25 +38,83 @@ SYNOPSIS " In computer software, a data access object (DAO) is an object that - provides an abstract interface to some type of database or persistence - mechanism, providing some specific operations without exposing details - of the database. It provides a mapping from application calls to the - persistence layer. This isolation separates the concerns of what data - accesses the application needs, in terms of domain-specific objects and - data types (the public interface of the DAO), and how these needs can be - satisfied with a specific DBMS, database schema, etc. (the - implementation of the DAO). - - " + provides an abstract interface to some type of database or other + persistence mechanism. By mapping application calls to the persistence + layer, DAOs provide some specific data operations without exposing + details of the database. This isolation supports the single + responsibility principle. It separates what data accesses the + application needs, in terms of domain-specific objects and data types + (the public interface of the DAO), from how these needs can be satisfied + with a specific DBMS, database schema, etc. (the implementation of the + DAO). + + " - http://en.wikipedia.org/wiki/Data_access_object + and this to say about the single responsibility principle + + " + + In object-oriented programming, the single responsibility principle + states that every class should have a single responsibility, and that + responsibility should be entirely encapsulated by the class. All its + services should be narrowly aligned with that responsibility. + + Responsibility [is defined] as a reason to change, and [single + responsibility means] that a class or module should have one, and only + one, reason to change. As an example, consider a module that compiles and + prints a report. Such a module can be changed for two reasons. First, + the content of the report can change. Second, the format of the report + can change. These two things change for very different causes; one + substantive, and one cosmetic. The single responsibility principle says + that these two aspects of the problem are really two separate + responsibilities, and should therefore be in separate classes or + modules. It would be a bad design to couple two things that change for + different reasons at different times. + + " + + - http://en.wikipedia.org/wiki/Single_responsibility_principle + + even though rails is the sweet, its ActiveRecord class violates (or, at + least, encourages a programmer to violate) the single responsibility + principle. uncle bob sums it up this way + + " + + The problem I have with ActiveRecord is that it creates confusion about + these two very different styles of programming. A database table is a + data structure. It has exposed data and no behavior. But an ActiveRecord + appears to be an object. It has “hidden” data, and exposed behavior. I + put the word “hidden” in quotes because the data is, in fact, not + hidden. Almost all ActiveRecord derivatives export the database columns + through accessors and mutators. Indeed, the Active Record is meant to be + used like a data structure. + + On the other hand, many people put business rule methods in their + ActiveRecord classes; which makes them appear to be objects. This leads + to a dilemma. On which side of the line does the Active Record really + fall? Is it an object? Or is it a data structure? + + " + + - http://programmers.stackexchange.com/questions/119352/does-the-activerecord-pattern-follow-encourage-the-solid-design-principles?answertab=oldest#tab-top + and " - Models are not data access objects... + + Jim Weirich, at the end of his SOLID Ruby Talk at the 2009 Ruby + Conference, asks the audience: "ActiveRecord objects implement a domain + concept and a persistence concept. Does this violate the SRP (Single + Responsibility Principle)?" The audience agrees that it does violate the + SRP. Jim asks if this bothers them. Many members of the audience say + yes. Why? It makes testing harder. It makes the persistence object a lot + heavier. + " - - http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller + - http://programmers.stackexchange.com/questions/119352/does-the-activerecord-pattern-follow-encourage-the-solid-design-principles#comment293734_119352 DESCRITPION @@ -134,7 +192,7 @@ DESCRITPION - forms and interfaces that involve dozens of models are as easy to deal with as simple ones. - - code can be optimized at the interface + - code can be optimized at the interface. READING http://blog.plataformatec.com.br/2012/03/barebone-models-to-use-with-actionpack-in-rails-4-0/ From 07e3bc0733cc9e49c6e2f077a993bb85963da91b Mon Sep 17 00:00:00 2001 From: Kerry Ivan Kurian Date: Sun, 13 Oct 2013 13:46:47 -0600 Subject: [PATCH 2/4] mo betta problem/solution background/motivation --- README | 69 +++++++++++++++++++++++++++++++++++++++++++++++++----------------- 1 file changed, 51 insertions(+), 18 deletions(-) diff --git a/README b/README index cc0ca30..0fcddf9 100644 --- a/README +++ b/README @@ -36,7 +36,6 @@ SYNOPSIS wikipedia has this to say about dao in general " - In computer software, a data access object (DAO) is an object that provides an abstract interface to some type of database or other persistence mechanism. By mapping application calls to the persistence @@ -47,14 +46,12 @@ SYNOPSIS (the public interface of the DAO), from how these needs can be satisfied with a specific DBMS, database schema, etc. (the implementation of the DAO). - " - http://en.wikipedia.org/wiki/Data_access_object and this to say about the single responsibility principle " - In object-oriented programming, the single responsibility principle states that every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its @@ -71,19 +68,31 @@ SYNOPSIS responsibilities, and should therefore be in separate classes or modules. It would be a bad design to couple two things that change for different reasons at different times. - " - - http://en.wikipedia.org/wiki/Single_responsibility_principle even though rails is the sweet, its ActiveRecord class violates (or, at least, encourages a programmer to violate) the single responsibility - principle. uncle bob sums it up this way + principle + + this leads to obvious problems " + Jim Weirich, at the end of his SOLID Ruby Talk at the 2009 Ruby + Conference, asks the audience: "ActiveRecord objects implement a domain + concept and a persistence concept. Does this violate the SRP (Single + Responsibility Principle)?" The audience agrees that it does violate the + SRP. Jim asks if this bothers them. Many members of the audience say + yes. Why? It makes testing harder. It makes the persistence object a lot + heavier. + " + - http://programmers.stackexchange.com/questions/119352/does-the-activerecord-pattern-follow-encourage-the-solid-design-principles#comment293734_119352 + and subtle yet sweeping consequences (as described by uncle bob) + + " The problem I have with ActiveRecord is that it creates confusion about - these two very different styles of programming. A database table is a + ... two very different styles of programming. A database table is a data structure. It has exposed data and no behavior. But an ActiveRecord appears to be an object. It has “hidden” data, and exposed behavior. I put the word “hidden” in quotes because the data is, in fact, not @@ -96,25 +105,49 @@ SYNOPSIS to a dilemma. On which side of the line does the Active Record really fall? Is it an object? Or is it a data structure? - " + This dilemma is the basis for the oft-cited impedance mismatch between + relational databases and object oriented languages. Tables are data + structures, not classes. Objects are encapsulated behavior, not database + rows. + + ... - - http://programmers.stackexchange.com/questions/119352/does-the-activerecord-pattern-follow-encourage-the-solid-design-principles?answertab=oldest#tab-top + The problem is that Active Records are data structures. Putting business + rule methods in them doesn’t turn them into true objects. In the end, + the algorithms that employ ActiveRecords are vulnerable to changes in + schema, and changes in type. They are not immune to changes in type, the + way algorithms that use objects are. - and + ... + So applications built around ActiveRecord are applications built around + data structures. And applications that are built around data structures + are procedural—they are not object oriented. The opportunity we miss + when we structure our applications around ActiveRecord is the + opportunity to use object oriented design. " + - https://sites.google.com/site/unclebobconsultingllc/active-record-vs-objects - Jim Weirich, at the end of his SOLID Ruby Talk at the 2009 Ruby - Conference, asks the audience: "ActiveRecord objects implement a domain - concept and a persistence concept. Does this violate the SRP (Single - Responsibility Principle)?" The audience agrees that it does violate the - SRP. Jim asks if this bothers them. Many members of the audience say - yes. Why? It makes testing harder. It makes the persistence object a lot - heavier. + and a clear solution (again, uncle bob -- emphasis added) " + I am not recommending against the use of ActiveRecord. I think the + pattern is very useful. **What I am advocating is a separation between the + application and ActiveRecord.** + + ActiveRecord belongs in the layer that separates the database from the + application. It makes a very convenient halfway-house between the hard + data structures of database tables, and the behavior exposing objects in + the application. + + **Applications should be designed and structured around objects, not data + structures. Those objects should expose business behaviors, and hide any + vestige of the database.** + " + - https://sites.google.com/site/unclebobconsultingllc/active-record-vs-objects + + welcome to the dao - - http://programmers.stackexchange.com/questions/119352/does-the-activerecord-pattern-follow-encourage-the-solid-design-principles#comment293734_119352 DESCRITPION From 16acaf4c5c1f3508b076b61d466dcb49ebf8b7fa Mon Sep 17 00:00:00 2001 From: Kerry Ivan Kurian Date: Sun, 13 Oct 2013 13:48:42 -0600 Subject: [PATCH 3/4] no markdown, no emphasis --- README | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/README b/README index 0fcddf9..a24e620 100644 --- a/README +++ b/README @@ -128,21 +128,21 @@ SYNOPSIS " - https://sites.google.com/site/unclebobconsultingllc/active-record-vs-objects - and a clear solution (again, uncle bob -- emphasis added) + and a clear solution (again, uncle bob) " I am not recommending against the use of ActiveRecord. I think the - pattern is very useful. **What I am advocating is a separation between the - application and ActiveRecord.** + pattern is very useful. What I am advocating is a separation between the + application and ActiveRecord. ActiveRecord belongs in the layer that separates the database from the application. It makes a very convenient halfway-house between the hard data structures of database tables, and the behavior exposing objects in the application. - **Applications should be designed and structured around objects, not data + Applications should be designed and structured around objects, not data structures. Those objects should expose business behaviors, and hide any - vestige of the database.** + vestige of the database. " - https://sites.google.com/site/unclebobconsultingllc/active-record-vs-objects From 4614426f7fc66c97850359b2b3153771065d41ef Mon Sep 17 00:00:00 2001 From: Kerry Ivan Kurian Date: Sun, 13 Oct 2013 13:51:05 -0600 Subject: [PATCH 4/4] spell bettah --- README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README b/README index a24e620..b56999b 100644 --- a/README +++ b/README @@ -149,7 +149,7 @@ SYNOPSIS welcome to the dao -DESCRITPION +DESCRIPTION API applications that are written on dao look like this in ruby