dao 5.3.3 → 5.4.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +8 -8
- data/10.patch +316 -0
- data/README +107 -16
- data/dao.gemspec +3 -3
- data/lib/dao.rb +1 -1
- data/lib/dao/form.rb +5 -0
- metadata +3 -3
- data/a.rb +0 -8
checksums.yaml
CHANGED
@@ -1,15 +1,15 @@
|
|
1
1
|
---
|
2
2
|
!binary "U0hBMQ==":
|
3
3
|
metadata.gz: !binary |-
|
4
|
-
|
4
|
+
MGZhZTE2YzNhMmEwMWIxMjBmZmNmMzFkNjliNjFjNzhmZWUwZTZkYg==
|
5
5
|
data.tar.gz: !binary |-
|
6
|
-
|
6
|
+
MGVmMzI5ZmMxNWJiZDYyYTFhYmQxMThhMzRiMjEyY2NkZDRkMGNlNA==
|
7
7
|
!binary "U0hBNTEy":
|
8
8
|
metadata.gz: !binary |-
|
9
|
-
|
10
|
-
|
11
|
-
|
9
|
+
ZGY4Mzk2YWYwMWQyYWIyZDVmMzkxZWNjYzIyZmY2Y2FjNDk0YzM3MTQ2NGNj
|
10
|
+
ZGMwNzQwODUwOWQ5Y2RlMjYwODJjMDE4Njg4NmEyMjkxNDFmZjdlMzE0MWEw
|
11
|
+
MTUwN2I0ZWRkZmExNTI0YjU2MmQ5ZmNmMzhlMGVmMGIxMmZlM2U=
|
12
12
|
data.tar.gz: !binary |-
|
13
|
-
|
14
|
-
|
15
|
-
|
13
|
+
Y2VmY2VmNGUyNjhjYjYyNGJkYzViNDgwNjdiODk0MzlhNzE2ZGRjZDE5ZjMy
|
14
|
+
ZWE0ODdiNWVhZDE3NjYzMmQ3NmY3NGY1N2ZkNTViYjVmZGJjYTE2YWUzZmEy
|
15
|
+
YzVkYWY5NzJkNDg1MDNiNTIxN2RkYThhNTY5Y2EwNjZiZjAyN2I=
|
data/10.patch
ADDED
@@ -0,0 +1,316 @@
|
|
1
|
+
From e8155d4abba61db094defcf1c6dc0c42d7f4f26c Mon Sep 17 00:00:00 2001
|
2
|
+
From: Kerry Ivan Kurian <kerry@dojo4.com>
|
3
|
+
Date: Sun, 13 Oct 2013 13:13:16 -0600
|
4
|
+
Subject: [PATCH 1/4] update teh readme
|
5
|
+
|
6
|
+
---
|
7
|
+
README | 84 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------
|
8
|
+
1 file changed, 71 insertions(+), 13 deletions(-)
|
9
|
+
|
10
|
+
diff --git a/README b/README
|
11
|
+
index 6d72aa7..cc0ca30 100644
|
12
|
+
--- a/README
|
13
|
+
+++ b/README
|
14
|
+
@@ -38,25 +38,83 @@ SYNOPSIS
|
15
|
+
"
|
16
|
+
|
17
|
+
In computer software, a data access object (DAO) is an object that
|
18
|
+
- provides an abstract interface to some type of database or persistence
|
19
|
+
- mechanism, providing some specific operations without exposing details
|
20
|
+
- of the database. It provides a mapping from application calls to the
|
21
|
+
- persistence layer. This isolation separates the concerns of what data
|
22
|
+
- accesses the application needs, in terms of domain-specific objects and
|
23
|
+
- data types (the public interface of the DAO), and how these needs can be
|
24
|
+
- satisfied with a specific DBMS, database schema, etc. (the
|
25
|
+
- implementation of the DAO).
|
26
|
+
-
|
27
|
+
- "
|
28
|
+
+ provides an abstract interface to some type of database or other
|
29
|
+
+ persistence mechanism. By mapping application calls to the persistence
|
30
|
+
+ layer, DAOs provide some specific data operations without exposing
|
31
|
+
+ details of the database. This isolation supports the single
|
32
|
+
+ responsibility principle. It separates what data accesses the
|
33
|
+
+ application needs, in terms of domain-specific objects and data types
|
34
|
+
+ (the public interface of the DAO), from how these needs can be satisfied
|
35
|
+
+ with a specific DBMS, database schema, etc. (the implementation of the
|
36
|
+
+ DAO).
|
37
|
+
+
|
38
|
+
+ "
|
39
|
+
- http://en.wikipedia.org/wiki/Data_access_object
|
40
|
+
|
41
|
+
+ and this to say about the single responsibility principle
|
42
|
+
+
|
43
|
+
+ "
|
44
|
+
+
|
45
|
+
+ In object-oriented programming, the single responsibility principle
|
46
|
+
+ states that every class should have a single responsibility, and that
|
47
|
+
+ responsibility should be entirely encapsulated by the class. All its
|
48
|
+
+ services should be narrowly aligned with that responsibility.
|
49
|
+
+
|
50
|
+
+ Responsibility [is defined] as a reason to change, and [single
|
51
|
+
+ responsibility means] that a class or module should have one, and only
|
52
|
+
+ one, reason to change. As an example, consider a module that compiles and
|
53
|
+
+ prints a report. Such a module can be changed for two reasons. First,
|
54
|
+
+ the content of the report can change. Second, the format of the report
|
55
|
+
+ can change. These two things change for very different causes; one
|
56
|
+
+ substantive, and one cosmetic. The single responsibility principle says
|
57
|
+
+ that these two aspects of the problem are really two separate
|
58
|
+
+ responsibilities, and should therefore be in separate classes or
|
59
|
+
+ modules. It would be a bad design to couple two things that change for
|
60
|
+
+ different reasons at different times.
|
61
|
+
+
|
62
|
+
+ "
|
63
|
+
+
|
64
|
+
+ - http://en.wikipedia.org/wiki/Single_responsibility_principle
|
65
|
+
+
|
66
|
+
+ even though rails is the sweet, its ActiveRecord class violates (or, at
|
67
|
+
+ least, encourages a programmer to violate) the single responsibility
|
68
|
+
+ principle. uncle bob sums it up this way
|
69
|
+
+
|
70
|
+
+ "
|
71
|
+
+
|
72
|
+
+ The problem I have with ActiveRecord is that it creates confusion about
|
73
|
+
+ these two very different styles of programming. A database table is a
|
74
|
+
+ data structure. It has exposed data and no behavior. But an ActiveRecord
|
75
|
+
+ appears to be an object. It has “hidden” data, and exposed behavior. I
|
76
|
+
+ put the word “hidden” in quotes because the data is, in fact, not
|
77
|
+
+ hidden. Almost all ActiveRecord derivatives export the database columns
|
78
|
+
+ through accessors and mutators. Indeed, the Active Record is meant to be
|
79
|
+
+ used like a data structure.
|
80
|
+
+
|
81
|
+
+ On the other hand, many people put business rule methods in their
|
82
|
+
+ ActiveRecord classes; which makes them appear to be objects. This leads
|
83
|
+
+ to a dilemma. On which side of the line does the Active Record really
|
84
|
+
+ fall? Is it an object? Or is it a data structure?
|
85
|
+
+
|
86
|
+
+ "
|
87
|
+
+
|
88
|
+
+ - http://programmers.stackexchange.com/questions/119352/does-the-activerecord-pattern-follow-encourage-the-solid-design-principles?answertab=oldest#tab-top
|
89
|
+
+
|
90
|
+
and
|
91
|
+
|
92
|
+
"
|
93
|
+
- Models are not data access objects...
|
94
|
+
+
|
95
|
+
+ Jim Weirich, at the end of his SOLID Ruby Talk at the 2009 Ruby
|
96
|
+
+ Conference, asks the audience: "ActiveRecord objects implement a domain
|
97
|
+
+ concept and a persistence concept. Does this violate the SRP (Single
|
98
|
+
+ Responsibility Principle)?" The audience agrees that it does violate the
|
99
|
+
+ SRP. Jim asks if this bothers them. Many members of the audience say
|
100
|
+
+ yes. Why? It makes testing harder. It makes the persistence object a lot
|
101
|
+
+ heavier.
|
102
|
+
+
|
103
|
+
"
|
104
|
+
|
105
|
+
- - http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
|
106
|
+
+ - http://programmers.stackexchange.com/questions/119352/does-the-activerecord-pattern-follow-encourage-the-solid-design-principles#comment293734_119352
|
107
|
+
|
108
|
+
DESCRITPION
|
109
|
+
|
110
|
+
@@ -134,7 +192,7 @@ DESCRITPION
|
111
|
+
- forms and interfaces that involve dozens of models are as easy to deal
|
112
|
+
with as simple ones.
|
113
|
+
|
114
|
+
- - code can be optimized at the interface
|
115
|
+
+ - code can be optimized at the interface.
|
116
|
+
|
117
|
+
READING
|
118
|
+
http://blog.plataformatec.com.br/2012/03/barebone-models-to-use-with-actionpack-in-rails-4-0/
|
119
|
+
|
120
|
+
From 07e3bc0733cc9e49c6e2f077a993bb85963da91b Mon Sep 17 00:00:00 2001
|
121
|
+
From: Kerry Ivan Kurian <kerry@dojo4.com>
|
122
|
+
Date: Sun, 13 Oct 2013 13:46:47 -0600
|
123
|
+
Subject: [PATCH 2/4] mo betta problem/solution background/motivation
|
124
|
+
|
125
|
+
---
|
126
|
+
README | 69 +++++++++++++++++++++++++++++++++++++++++++++++++-----------------
|
127
|
+
1 file changed, 51 insertions(+), 18 deletions(-)
|
128
|
+
|
129
|
+
diff --git a/README b/README
|
130
|
+
index cc0ca30..0fcddf9 100644
|
131
|
+
--- a/README
|
132
|
+
+++ b/README
|
133
|
+
@@ -36,7 +36,6 @@ SYNOPSIS
|
134
|
+
wikipedia has this to say about dao in general
|
135
|
+
|
136
|
+
"
|
137
|
+
-
|
138
|
+
In computer software, a data access object (DAO) is an object that
|
139
|
+
provides an abstract interface to some type of database or other
|
140
|
+
persistence mechanism. By mapping application calls to the persistence
|
141
|
+
@@ -47,14 +46,12 @@ SYNOPSIS
|
142
|
+
(the public interface of the DAO), from how these needs can be satisfied
|
143
|
+
with a specific DBMS, database schema, etc. (the implementation of the
|
144
|
+
DAO).
|
145
|
+
-
|
146
|
+
"
|
147
|
+
- http://en.wikipedia.org/wiki/Data_access_object
|
148
|
+
|
149
|
+
and this to say about the single responsibility principle
|
150
|
+
|
151
|
+
"
|
152
|
+
-
|
153
|
+
In object-oriented programming, the single responsibility principle
|
154
|
+
states that every class should have a single responsibility, and that
|
155
|
+
responsibility should be entirely encapsulated by the class. All its
|
156
|
+
@@ -71,19 +68,31 @@ SYNOPSIS
|
157
|
+
responsibilities, and should therefore be in separate classes or
|
158
|
+
modules. It would be a bad design to couple two things that change for
|
159
|
+
different reasons at different times.
|
160
|
+
-
|
161
|
+
"
|
162
|
+
-
|
163
|
+
- http://en.wikipedia.org/wiki/Single_responsibility_principle
|
164
|
+
|
165
|
+
even though rails is the sweet, its ActiveRecord class violates (or, at
|
166
|
+
least, encourages a programmer to violate) the single responsibility
|
167
|
+
- principle. uncle bob sums it up this way
|
168
|
+
+ principle
|
169
|
+
+
|
170
|
+
+ this leads to obvious problems
|
171
|
+
|
172
|
+
"
|
173
|
+
+ Jim Weirich, at the end of his SOLID Ruby Talk at the 2009 Ruby
|
174
|
+
+ Conference, asks the audience: "ActiveRecord objects implement a domain
|
175
|
+
+ concept and a persistence concept. Does this violate the SRP (Single
|
176
|
+
+ Responsibility Principle)?" The audience agrees that it does violate the
|
177
|
+
+ SRP. Jim asks if this bothers them. Many members of the audience say
|
178
|
+
+ yes. Why? It makes testing harder. It makes the persistence object a lot
|
179
|
+
+ heavier.
|
180
|
+
+ "
|
181
|
+
+ - http://programmers.stackexchange.com/questions/119352/does-the-activerecord-pattern-follow-encourage-the-solid-design-principles#comment293734_119352
|
182
|
+
|
183
|
+
+ and subtle yet sweeping consequences (as described by uncle bob)
|
184
|
+
+
|
185
|
+
+ "
|
186
|
+
The problem I have with ActiveRecord is that it creates confusion about
|
187
|
+
- these two very different styles of programming. A database table is a
|
188
|
+
+ ... two very different styles of programming. A database table is a
|
189
|
+
data structure. It has exposed data and no behavior. But an ActiveRecord
|
190
|
+
appears to be an object. It has “hidden” data, and exposed behavior. I
|
191
|
+
put the word “hidden” in quotes because the data is, in fact, not
|
192
|
+
@@ -96,25 +105,49 @@ SYNOPSIS
|
193
|
+
to a dilemma. On which side of the line does the Active Record really
|
194
|
+
fall? Is it an object? Or is it a data structure?
|
195
|
+
|
196
|
+
- "
|
197
|
+
+ This dilemma is the basis for the oft-cited impedance mismatch between
|
198
|
+
+ relational databases and object oriented languages. Tables are data
|
199
|
+
+ structures, not classes. Objects are encapsulated behavior, not database
|
200
|
+
+ rows.
|
201
|
+
+
|
202
|
+
+ ...
|
203
|
+
|
204
|
+
- - http://programmers.stackexchange.com/questions/119352/does-the-activerecord-pattern-follow-encourage-the-solid-design-principles?answertab=oldest#tab-top
|
205
|
+
+ The problem is that Active Records are data structures. Putting business
|
206
|
+
+ rule methods in them doesn’t turn them into true objects. In the end,
|
207
|
+
+ the algorithms that employ ActiveRecords are vulnerable to changes in
|
208
|
+
+ schema, and changes in type. They are not immune to changes in type, the
|
209
|
+
+ way algorithms that use objects are.
|
210
|
+
|
211
|
+
- and
|
212
|
+
+ ...
|
213
|
+
|
214
|
+
+ So applications built around ActiveRecord are applications built around
|
215
|
+
+ data structures. And applications that are built around data structures
|
216
|
+
+ are procedural—they are not object oriented. The opportunity we miss
|
217
|
+
+ when we structure our applications around ActiveRecord is the
|
218
|
+
+ opportunity to use object oriented design.
|
219
|
+
"
|
220
|
+
+ - https://sites.google.com/site/unclebobconsultingllc/active-record-vs-objects
|
221
|
+
|
222
|
+
- Jim Weirich, at the end of his SOLID Ruby Talk at the 2009 Ruby
|
223
|
+
- Conference, asks the audience: "ActiveRecord objects implement a domain
|
224
|
+
- concept and a persistence concept. Does this violate the SRP (Single
|
225
|
+
- Responsibility Principle)?" The audience agrees that it does violate the
|
226
|
+
- SRP. Jim asks if this bothers them. Many members of the audience say
|
227
|
+
- yes. Why? It makes testing harder. It makes the persistence object a lot
|
228
|
+
- heavier.
|
229
|
+
+ and a clear solution (again, uncle bob -- emphasis added)
|
230
|
+
|
231
|
+
"
|
232
|
+
+ I am not recommending against the use of ActiveRecord. I think the
|
233
|
+
+ pattern is very useful. **What I am advocating is a separation between the
|
234
|
+
+ application and ActiveRecord.**
|
235
|
+
+
|
236
|
+
+ ActiveRecord belongs in the layer that separates the database from the
|
237
|
+
+ application. It makes a very convenient halfway-house between the hard
|
238
|
+
+ data structures of database tables, and the behavior exposing objects in
|
239
|
+
+ the application.
|
240
|
+
+
|
241
|
+
+ **Applications should be designed and structured around objects, not data
|
242
|
+
+ structures. Those objects should expose business behaviors, and hide any
|
243
|
+
+ vestige of the database.**
|
244
|
+
+ "
|
245
|
+
+ - https://sites.google.com/site/unclebobconsultingllc/active-record-vs-objects
|
246
|
+
+
|
247
|
+
+ welcome to the dao
|
248
|
+
|
249
|
+
- - http://programmers.stackexchange.com/questions/119352/does-the-activerecord-pattern-follow-encourage-the-solid-design-principles#comment293734_119352
|
250
|
+
|
251
|
+
DESCRITPION
|
252
|
+
|
253
|
+
|
254
|
+
From 16acaf4c5c1f3508b076b61d466dcb49ebf8b7fa Mon Sep 17 00:00:00 2001
|
255
|
+
From: Kerry Ivan Kurian <kerry@dojo4.com>
|
256
|
+
Date: Sun, 13 Oct 2013 13:48:42 -0600
|
257
|
+
Subject: [PATCH 3/4] no markdown, no emphasis
|
258
|
+
|
259
|
+
---
|
260
|
+
README | 10 +++++-----
|
261
|
+
1 file changed, 5 insertions(+), 5 deletions(-)
|
262
|
+
|
263
|
+
diff --git a/README b/README
|
264
|
+
index 0fcddf9..a24e620 100644
|
265
|
+
--- a/README
|
266
|
+
+++ b/README
|
267
|
+
@@ -128,21 +128,21 @@ SYNOPSIS
|
268
|
+
"
|
269
|
+
- https://sites.google.com/site/unclebobconsultingllc/active-record-vs-objects
|
270
|
+
|
271
|
+
- and a clear solution (again, uncle bob -- emphasis added)
|
272
|
+
+ and a clear solution (again, uncle bob)
|
273
|
+
|
274
|
+
"
|
275
|
+
I am not recommending against the use of ActiveRecord. I think the
|
276
|
+
- pattern is very useful. **What I am advocating is a separation between the
|
277
|
+
- application and ActiveRecord.**
|
278
|
+
+ pattern is very useful. What I am advocating is a separation between the
|
279
|
+
+ application and ActiveRecord.
|
280
|
+
|
281
|
+
ActiveRecord belongs in the layer that separates the database from the
|
282
|
+
application. It makes a very convenient halfway-house between the hard
|
283
|
+
data structures of database tables, and the behavior exposing objects in
|
284
|
+
the application.
|
285
|
+
|
286
|
+
- **Applications should be designed and structured around objects, not data
|
287
|
+
+ Applications should be designed and structured around objects, not data
|
288
|
+
structures. Those objects should expose business behaviors, and hide any
|
289
|
+
- vestige of the database.**
|
290
|
+
+ vestige of the database.
|
291
|
+
"
|
292
|
+
- https://sites.google.com/site/unclebobconsultingllc/active-record-vs-objects
|
293
|
+
|
294
|
+
|
295
|
+
From 4614426f7fc66c97850359b2b3153771065d41ef Mon Sep 17 00:00:00 2001
|
296
|
+
From: Kerry Ivan Kurian <kerry@dojo4.com>
|
297
|
+
Date: Sun, 13 Oct 2013 13:51:05 -0600
|
298
|
+
Subject: [PATCH 4/4] spell bettah
|
299
|
+
|
300
|
+
---
|
301
|
+
README | 2 +-
|
302
|
+
1 file changed, 1 insertion(+), 1 deletion(-)
|
303
|
+
|
304
|
+
diff --git a/README b/README
|
305
|
+
index a24e620..b56999b 100644
|
306
|
+
--- a/README
|
307
|
+
+++ b/README
|
308
|
+
@@ -149,7 +149,7 @@ SYNOPSIS
|
309
|
+
welcome to the dao
|
310
|
+
|
311
|
+
|
312
|
+
-DESCRITPION
|
313
|
+
+DESCRIPTION
|
314
|
+
|
315
|
+
API
|
316
|
+
applications that are written on dao look like this in ruby
|
data/README
CHANGED
@@ -36,29 +36,120 @@ SYNOPSIS
|
|
36
36
|
wikipedia has this to say about dao in general
|
37
37
|
|
38
38
|
"
|
39
|
-
|
40
39
|
In computer software, a data access object (DAO) is an object that
|
41
|
-
provides an abstract interface to some type of database or
|
42
|
-
mechanism
|
43
|
-
|
44
|
-
|
45
|
-
|
46
|
-
|
47
|
-
|
48
|
-
implementation of the
|
49
|
-
|
50
|
-
"
|
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
|
+
"
|
51
50
|
- http://en.wikipedia.org/wiki/Data_access_object
|
52
51
|
|
53
|
-
and
|
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)
|
54
132
|
|
55
133
|
"
|
56
|
-
|
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.
|
57
146
|
"
|
147
|
+
- https://sites.google.com/site/unclebobconsultingllc/active-record-vs-objects
|
148
|
+
|
149
|
+
welcome to the dao
|
58
150
|
|
59
|
-
- http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
|
60
151
|
|
61
|
-
|
152
|
+
DESCRIPTION
|
62
153
|
|
63
154
|
API
|
64
155
|
applications that are written on dao look like this in ruby
|
@@ -134,7 +225,7 @@ DESCRITPION
|
|
134
225
|
- forms and interfaces that involve dozens of models are as easy to deal
|
135
226
|
with as simple ones.
|
136
227
|
|
137
|
-
- code can be optimized at the interface
|
228
|
+
- code can be optimized at the interface.
|
138
229
|
|
139
230
|
READING
|
140
231
|
http://blog.plataformatec.com.br/2012/03/barebone-models-to-use-with-actionpack-in-rails-4-0/
|
data/dao.gemspec
CHANGED
@@ -3,18 +3,18 @@
|
|
3
3
|
|
4
4
|
Gem::Specification::new do |spec|
|
5
5
|
spec.name = "dao"
|
6
|
-
spec.version = "5.
|
6
|
+
spec.version = "5.4.0"
|
7
7
|
spec.platform = Gem::Platform::RUBY
|
8
8
|
spec.summary = "dao"
|
9
9
|
spec.description = "presenter, conducer, api, and better form objects for you rails' pleasure"
|
10
10
|
spec.license = "same as ruby's"
|
11
11
|
|
12
12
|
spec.files =
|
13
|
-
["
|
13
|
+
["10.patch",
|
14
|
+
"Gemfile",
|
14
15
|
"Gemfile.lock",
|
15
16
|
"README",
|
16
17
|
"Rakefile",
|
17
|
-
"a.rb",
|
18
18
|
"dao.gemspec",
|
19
19
|
"lib",
|
20
20
|
"lib/dao",
|
data/lib/dao.rb
CHANGED
data/lib/dao/form.rb
CHANGED
@@ -387,6 +387,7 @@ module Dao
|
|
387
387
|
end
|
388
388
|
|
389
389
|
if options[:multiple]
|
390
|
+
name = name.to_s
|
390
391
|
name += '[]'
|
391
392
|
end
|
392
393
|
|
@@ -658,5 +659,9 @@ module Dao
|
|
658
659
|
string = string.titleize if string.respond_to?(:titleize)
|
659
660
|
string
|
660
661
|
end
|
662
|
+
|
663
|
+
def capture(*args, &block)
|
664
|
+
tagz(*args, &block)
|
665
|
+
end
|
661
666
|
end
|
662
667
|
end
|
metadata
CHANGED
@@ -1,14 +1,14 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: dao
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
version: 5.
|
4
|
+
version: 5.4.0
|
5
5
|
platform: ruby
|
6
6
|
authors:
|
7
7
|
- Ara T. Howard
|
8
8
|
autorequire:
|
9
9
|
bindir: bin
|
10
10
|
cert_chain: []
|
11
|
-
date:
|
11
|
+
date: 2015-03-03 00:00:00.000000000 Z
|
12
12
|
dependencies:
|
13
13
|
- !ruby/object:Gem::Dependency
|
14
14
|
name: rails
|
@@ -156,11 +156,11 @@ executables: []
|
|
156
156
|
extensions: []
|
157
157
|
extra_rdoc_files: []
|
158
158
|
files:
|
159
|
+
- 10.patch
|
159
160
|
- Gemfile
|
160
161
|
- Gemfile.lock
|
161
162
|
- README
|
162
163
|
- Rakefile
|
163
|
-
- a.rb
|
164
164
|
- dao.gemspec
|
165
165
|
- lib/dao.rb
|
166
166
|
- lib/dao/active_record.rb
|