-
Notifications
You must be signed in to change notification settings - Fork 43
Expand file tree
/
Copy pathNotes.ad
More file actions
112 lines (74 loc) · 4.98 KB
/
Copy pathNotes.ad
File metadata and controls
112 lines (74 loc) · 4.98 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
* http://solnic.eu/2011/08/01/making-activerecord-models-thin.html[Making ActiveRecord Models Thin] - great blog post (and comment stream) from August 1, 2011 discussing separating behavior and state in Rails apps.
* http://solnic.eu/2013/01/23/mutation-testing-with-mutant.html
* http://solnic.eu/2012/12/20/datamapper-2-status-and-roadmap.html[DataMapper 2 Status and Roadmap] - mentions the following cool Gems that have been extraced from DataMapper:
** https://github.com/dkubb/adamantium[Adamantium] - helps in building immutable objects
** https://github.com/dkubb/ice_nine[IceNine] - deep freezing objects
** https://github.com/dkubb/equalizer[Equalizer] - builds equality methods for you
** DescendantsTracker
* Sample usage for DataMapper 2. Kinda cool:
```
# In DataMapper 2 we don't pollute global constants with shared state.
# That's why we decided to use an environment object that *you*
# create and use do build mappers and configure everything.
# Let's call it "datamapper" :)
datamapper = DataMapper::Environment.new
# You use environment object to establish connection with a db
datamapper.setup :postgres, :uri => "postgres://localhost/test"
# So let's say we have 2 domain objects Page and Book
class Page
include DataMapper::Model
attribute :id, Integer
attribute :content, String
end
class Book
include DataMapper::Model
attribute :isbn, String
attribute :title, String
attribute :author, String
attribute :pages, Array[Page]
end
# You use environment object to build mappers
datamapper.build(Page, :postgres) do
key(:id)
end
datamapper.build(Book, :postgres) do
key(:isbn)
# here we establish a relationship between page and books
has 0..n, :pages, Page
end
# we need to finalize the env now
datamapper.finalize
# to access a mapper you use #[] method and model constant
# so to fetch all books with their pages you just do:
datamapper[Book].include(:pages).all
# Query API is pretty similar to what you already know
datamapper[Book].find(:author => 'John Doe').limit(10).offset(2)
```
== Data Mapper Pattern
* http://stackoverflow.com/questions/13550690/how-is-the-data-mapper-pattern-different-from-the-repository-pattern
----
http://stackoverflow.com/questions/13550690/how-is-the-data-mapper-pattern-different-from-the-repository-pattern
----
http://www.martinfowler.com/eaaCatalog/dataMapper.html[Data Mapper -] - A layer of Mappers (473) that moves data between objects and a database while keeping them independent of each other and the mapper itself.
== UIs in Ruby
What about DTOs?
[quote, http://stackoverflow.com/questions/3284917/ruby-on-rails-dto-objects-where-do-you-store-them]
____
The Rails convention is not to use distributed tiers for controller and view layers. The separation is there, but it is logical and relatively thin/lightweight compared to the types of frameworks you see in Java land.
The basic architecture is that the controller sets instance variables that are available in the corresponding view. In the general case, the instance variables will be model instances or collections of model instances (coming from the database). Models should be the core of your business logic. Controllers coordinate flows of data. Views display it. Helpers are used to format display values in the view ... anything that takes a model value and does something just for display purposes (you may find that a helper method used repeatedly may actually be better off on the model itself).
However, if you find that a view needs knowledge of many different models, you might find it easier to wrap models into another object at a higher-level of abstraction. Nothing prevents you from creating non-active-record objects that collect and coordinate your actual AR models. You can then instantiate these objects in the controller, and have them available to the view. You generally have to be at a pretty dense level of complexity in the controller to need this type of thing.
I would tend to throw such objects into apps/models - Rails already loads everything in this directory, keeps things easy from a config/expectation point of view.
____
=== Padrino
* Guides - http://www.padrinorb.com/guides
* https://leanpub.com/padrino - content at https://github.com/matthias-guenther/padrino-book
* Recipes - https://github.com/padrino/padrino-recipes
* http://www.slideshare.net/victorbstan/introduction-to-padrino-9450994
=== Padrino Bugs (found so far)
* http://stackoverflow.com/questions/16368016/bundle-update-for-padrino-app-could-not-find-compatible-versions-for-tilt[Gemfile: gem 'tilt', '1.3.7']
* post.rb - Put Text in quotes per http://rubyflewtoo.blogspot.com/2012/08/padrino-datamapper-rake-uninitialized.html
# Sinatra
* Sample apps - http://www.sinatrarb.com/wild.html
== Specification Pattern
* http://www.lukeredpath.co.uk/blog/introduction-to-activespec.html[ActiveSpec] - Ruby implementation of the Specification pattern from DDD. Written in 2006!
* http://robuye.blogspot.com/2013/05/specification-pattern-with-ruby-basics.html[Specification Pattern with Ruby - basics]