what’s the best place for code that’s used in several controllers?
i have a site with several namespaces.
one for admin and one for client (and some more)
adding a new client is a (relative) complex process
involving entries in several tables and creating folders
to upload files.
for example a client can create his own account but the admin can do
the same of course, so they share a lot of code.
does this code belong to the model since it’s business logic?
but then the client model would make entries in the address model (and a
few more)
application.rb would be another option, but it’s quite a lot of code
(and the client controller is not the only one), so this would become a
very large file then…
or is it better to create a lib (or several libs)?
make one lib per controller? or one lib per model?
What’s the best practice to place this shared logic?
does this code belong to the model since it’s business logic?
I think this statement pretty much sums it up. I am not sure why a
client model writing out it’s own address (or anything like it) would
be an issue. What you’re really saying is that you are willing to
delegate to the client object how it chooses to persist its own
address info. Whether that’s a composed object within the client
record or an associated (has_one) address should not matter to the
person using it – only that client.address returns a valid address.
If adding a new client is that complex, I’d consider moving the logic to
a
Factory. While complex creation logic almost certainly belongs in the
Domain
layer, it doesn’t have to be placed in the model class itself. In fact,
placing it in the model class can pollute it with extra
responsibilities.
And, by their very nature as implementations of the ActiveRecord pattern
[
P of EAA: Active Record ], models in Rails
already have two responsibilities, domain behavior and persistence.
The DDD Quickly book from InfoQ [
http://infoq.com/books/domain-driven-design-quickly ] is a good
introduction
to Domain Driven Design, which is the basis of my recommendation.
Regards,
Craig
Hi Craig,
I’m fairly new to the Rails framework. I’ve been using DDD techniques
in other environments. I noticed that you mentioned Rails models have
more than one responsibility. With regards to persistence, has any
application and/or book touched on removing persistence away from the
domain? I know ActiveRecord seems to be a major part of the framework
and I like the ActiveRecord pattern for some things, but I’m curious
about other options.
Thanks,
Shane
On May 6, 11:11 am, “Craig D.” [email protected]
Shane,
I only know that many people strive to limit their ActiveRecord models
to
domain + persistence by moving logic to other objects. I think many
people
mistakenly stick to just using models, views and controllers when they
come
to Rails, instead of creating, for example, other plain Ruby classes and
modules to break up responsibilities.
I don’t know if there are other persistence options for Rails. Merb [
http://merbivore.com/ ], however, supports Sequel and DataMapper in
addition
to ActiveRecord. I haven’t yet used Merb, Sequel or DataMapper, but
they’re
on my to-do list. Give them a look.
Craig
Thanks Craig and Andy.
I installed the gem for Merb, but haven’t done anything with it yet,
though. I’ll take a look at it today as well as the others. A lot of
good stuff to take a look at today. I appreciate it.
Shane
Another option that may be familiar from other environments is rbatis,
the Ruby port of the iBatis ORM by ThoughtWorks. I’ve used it with
some success in the past. My one complaint about the solution was
that it required you to create the maps in the class rather than in
some external (xml/yml/etc) file. However, I’ve recently been playing
with the AppConfig plugin to try to get around some of those issues.
Anyway, it’s another option in the sphere that DataMapper fills.