dao 5.6.1 → 7.0.0

Sign up to get free protection for your applications and to get access to all the features.
data/README DELETED
@@ -1,256 +0,0 @@
1
- NAME
2
- dao
3
-
4
- SYNOPSIS
5
- a sa-weet-ass library for structuring rails applications using the 'data
6
- access object' design pattern. dao consists of two main data access
7
- objects, *api* objects and *conducer* objects. conducers combine the
8
- presenter pattern with the conductor pattern.
9
-
10
-
11
- API
12
-
13
- class Api < Dao::Api
14
- call('/posts') do
15
- get do
16
- data[:posts] = Post.all.map{|post| post.attributes}
17
- end
18
-
19
- post do
20
- post = Post.new(params[:post])
21
-
22
- if post.save
23
- data[:post] = post.attributes
24
- else
25
- status 420
26
- end
27
- end
28
- end
29
- end
30
-
31
- CONDUCER
32
-
33
- # TODO
34
-
35
-
36
- wikipedia has this to say about dao in general
37
-
38
- "
39
- In computer software, a data access object (DAO) is an object that
40
- provides an abstract interface to some type of database or other
41
- persistence mechanism. By mapping application calls to the persistence
42
- layer, DAOs provide some specific data operations without exposing
43
- details of the database. This isolation supports the single
44
- responsibility principle. It separates what data accesses the
45
- application needs, in terms of domain-specific objects and data types
46
- (the public interface of the DAO), from how these needs can be satisfied
47
- with a specific DBMS, database schema, etc. (the implementation of the
48
- DAO).
49
- "
50
- - http://en.wikipedia.org/wiki/Data_access_object
51
-
52
- and this to say about the single responsibility principle
53
-
54
- "
55
- In object-oriented programming, the single responsibility principle
56
- states that every class should have a single responsibility, and that
57
- responsibility should be entirely encapsulated by the class. All its
58
- services should be narrowly aligned with that responsibility.
59
-
60
- Responsibility [is defined] as a reason to change, and [single
61
- responsibility means] that a class or module should have one, and only
62
- one, reason to change. As an example, consider a module that compiles and
63
- prints a report. Such a module can be changed for two reasons. First,
64
- the content of the report can change. Second, the format of the report
65
- can change. These two things change for very different causes; one
66
- substantive, and one cosmetic. The single responsibility principle says
67
- that these two aspects of the problem are really two separate
68
- responsibilities, and should therefore be in separate classes or
69
- modules. It would be a bad design to couple two things that change for
70
- different reasons at different times.
71
- "
72
- - http://en.wikipedia.org/wiki/Single_responsibility_principle
73
-
74
- even though rails is the sweet, its ActiveRecord class violates (or, at
75
- least, encourages a programmer to violate) the single responsibility
76
- principle
77
-
78
- this leads to obvious problems
79
-
80
- "
81
- Jim Weirich, at the end of his SOLID Ruby Talk at the 2009 Ruby
82
- Conference, asks the audience: "ActiveRecord objects implement a domain
83
- concept and a persistence concept. Does this violate the SRP (Single
84
- Responsibility Principle)?" The audience agrees that it does violate the
85
- SRP. Jim asks if this bothers them. Many members of the audience say
86
- yes. Why? It makes testing harder. It makes the persistence object a lot
87
- heavier.
88
- "
89
- - http://programmers.stackexchange.com/questions/119352/does-the-activerecord-pattern-follow-encourage-the-solid-design-principles#comment293734_119352
90
-
91
- and subtle yet sweeping consequences (as described by uncle bob)
92
-
93
- "
94
- The problem I have with ActiveRecord is that it creates confusion about
95
- ... two very different styles of programming. A database table is a
96
- data structure. It has exposed data and no behavior. But an ActiveRecord
97
- appears to be an object. It has “hidden” data, and exposed behavior. I
98
- put the word “hidden” in quotes because the data is, in fact, not
99
- hidden. Almost all ActiveRecord derivatives export the database columns
100
- through accessors and mutators. Indeed, the Active Record is meant to be
101
- used like a data structure.
102
-
103
- On the other hand, many people put business rule methods in their
104
- ActiveRecord classes; which makes them appear to be objects. This leads
105
- to a dilemma. On which side of the line does the Active Record really
106
- fall? Is it an object? Or is it a data structure?
107
-
108
- This dilemma is the basis for the oft-cited impedance mismatch between
109
- relational databases and object oriented languages. Tables are data
110
- structures, not classes. Objects are encapsulated behavior, not database
111
- rows.
112
-
113
- ...
114
-
115
- The problem is that Active Records are data structures. Putting business
116
- rule methods in them doesn’t turn them into true objects. In the end,
117
- the algorithms that employ ActiveRecords are vulnerable to changes in
118
- schema, and changes in type. They are not immune to changes in type, the
119
- way algorithms that use objects are.
120
-
121
- ...
122
-
123
- So applications built around ActiveRecord are applications built around
124
- data structures. And applications that are built around data structures
125
- are procedural—they are not object oriented. The opportunity we miss
126
- when we structure our applications around ActiveRecord is the
127
- opportunity to use object oriented design.
128
- "
129
- - https://sites.google.com/site/unclebobconsultingllc/active-record-vs-objects
130
-
131
- and a clear solution (again, uncle bob)
132
-
133
- "
134
- I am not recommending against the use of ActiveRecord. I think the
135
- pattern is very useful. What I am advocating is a separation between the
136
- application and ActiveRecord.
137
-
138
- ActiveRecord belongs in the layer that separates the database from the
139
- application. It makes a very convenient halfway-house between the hard
140
- data structures of database tables, and the behavior exposing objects in
141
- the application.
142
-
143
- Applications should be designed and structured around objects, not data
144
- structures. Those objects should expose business behaviors, and hide any
145
- vestige of the database.
146
- "
147
- - https://sites.google.com/site/unclebobconsultingllc/active-record-vs-objects
148
-
149
- welcome to the dao
150
-
151
-
152
- DESCRIPTION
153
-
154
- API
155
- applications that are written on dao look like this in ruby
156
-
157
- result = api.call('/posts/new', params)
158
-
159
- and like this in javascript
160
-
161
- result = api.call('/posts/new', params)
162
-
163
- in command-line applications they look like this
164
-
165
- result = api.call('/posts/new', params)
166
-
167
- and in tests this syntax is used
168
-
169
- result = api.call('/posts/new', params)
170
-
171
- when a developer wants to understand the interface of a dao application
172
- she does this
173
-
174
- vi app/api.rb
175
-
176
- when a developer of a dao application wants to play with a dao application
177
- interactively she does
178
-
179
- (rails console)
180
-
181
- > api = Api.new result = api.call('/posts/new', params)
182
-
183
- when a remote client wants to understand the api of a dao application she
184
- does
185
-
186
- curl --silent http://dao.app.com/api | less
187
-
188
-
189
-
190
- this kind of brutally consistent interface is made possible by structuring
191
- access to data around the finest data structure of all time - the hash.
192
- in the case of dao the hash is a well structured and slightly clever hash,
193
- but a simple hash interface is the basis of every bit of goodness dao has
194
- to offer.
195
-
196
- in dao, application developers do not bring models into controllers and,
197
- especially not into views. instead, a unified interface to application
198
- logic and data is used everywhere: in tests, in controllers, from the
199
- command-line, and also from javascript.
200
-
201
- this seperation of concerns brings with it many, many desirable qualities:
202
-
203
- - total seperation of concerns between the front and back end of a web
204
- application. when developers are using dao changes to the data model
205
- have zero effect on controllers and views.
206
-
207
- - issues related to having models in controllers and views such as
208
- difficulty reasoning about caching and n+1 queries in views killing
209
- the db simply disappear.
210
-
211
- - bad programming practices like using quasi-global variables
212
- (current_user) or decorating models with view specific attributes
213
- (password_verification) are no longer needed.
214
-
215
- - developers are able to reason over the abilities of an application by
216
- reading only a few source files.
217
-
218
- - databases can be swapped, mixed, or alternate storage/caching
219
- mechanisms added at any time without affecting the application's
220
- controllers or views.
221
-
222
- - transition from form based views to semi-ajax ones to fully-ajax ones
223
- is direct.
224
-
225
- - forms and interfaces that involve dozens of models are as easy to deal
226
- with as simple ones.
227
-
228
- - code can be optimized at the interface.
229
-
230
- READING
231
- http://blog.plataformatec.com.br/2012/03/barebone-models-to-use-with-actionpack-in-rails-4-0/
232
- http://martinfowler.com/eaaCatalog/serviceLayer.html
233
- http://blog.firsthand.ca/2011/10/rails-is-not-your-application.html
234
- http://best-practice-software-engineering.ifs.tuwien.ac.at/patterns/dao.html
235
- http://www.codefutures.com/data-access-object/
236
- http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
237
- http://www.paperplanes.de/2010/5/7/activerecord_callbacks_ruined_my_life.html
238
- http://google-styleguide.googlecode.com/svn/trunk/jsoncstyleguide.xml
239
- http://pragdave.blogs.pragprog.com/pragdave/2007/03/the_radar_archi.html
240
- http://borisstaal.com/post/22586260753/mvc-in-a-browser-vs-reality
241
-
242
-
243
- INSTALL
244
- gem 'dao', :path => File.expand_path('..') ### Gemfile
245
- rails generate dao api
246
- vim -o app/api.rb app/controllers/api_controller.rb
247
- curl --silent http://0.0.0.0:3000/api
248
- curl --silent http://0.0.0.0:3000/api/ping
249
-
250
- HISTORY
251
- 4.0.0
252
- - dao depends has tied itself to rails, for better or worse...
253
- - drop custom form encoding. just use a rack-like approach.
254
- - dao form parameter encoding has changed slightly to 'dao[/api/path][x,y,z]=42'
255
- - dao form paramters are now preparsed in a before filter
256
-