http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660@Mats Yeah, the Model wouldn't hold a reference to the Formatter. If I'm honest, I don't fully "get" what should and shouldn't go in the service layer :) I guess that formatting logic *is* often duplicated across several "clients", so the service layer might be as good a place as any. Either way, I think that formatters should be "clost to hand" - a bit like sticking a toolkit in the boot of your car :) Will check out that post of yours... http://ayende.com/2816/skinny-controller-fat-model#comment10http://ayende.com/2816/skinny-controller-fat-model#comment10Tue, 02 Oct 2007 10:18:00 GMTTobin, But wouldn't (or at least couldn't) the PersonFormatter be part of the Service Layer? in the MVC example, wouldn't it be enough that the controller knows of the PersonFormatter - no Model classes would need to have references to it, right? I just added a post where I describe how I think Obese Domain Models is a widespread enough problem that it should be regarded as an anti-pattern. http://www.matshelander.com/wordpress/?p=75 /Mats http://ayende.com/2816/skinny-controller-fat-model#comment9http://ayende.com/2816/skinny-controller-fat-model#comment9Mon, 01 Oct 2007 11:33:03 GMTI agree with Scott; I always think that you can just re-apply SRP to solve many of these bloated model problems, making finer cuts to pull responsibilites out. Jamis post is great and proves the point really well IMHO. If this particular model got fat, then you could extract "formatting" issues from the model and put them in a formatter or helper :) Therefore, I'd take the knife and make this kind of incision: PersonFormatter.name( a_person ) PersonFormatter.pseudo_id( a_person ) http://ayende.com/2816/skinny-controller-fat-model#comment8http://ayende.com/2816/skinny-controller-fat-model#comment8Mon, 01 Oct 2007 11:00:25 GMTAndrew, Yeah, Boo does opens up some very interesting possibilities in this regard, because the cost of using a mixin is removed using this approach. http://ayende.com/2816/skinny-controller-fat-model#comment7http://ayende.com/2816/skinny-controller-fat-model#comment7Mon, 01 Oct 2007 05:27:47 GMTMats, For the simple reason that is is a fair amount of work, and not nearly as easy and natural as it should be http://ayende.com/2816/skinny-controller-fat-model#comment6http://ayende.com/2816/skinny-controller-fat-model#comment6Mon, 01 Oct 2007 05:22:59 GMTIf you are using Boo, then maybe there is syntactic macro to implement an interface by calling a given implementation object. Something like: public class MyLargeThing implements IFoo, IBar: [Proxy(IFoo)] _foo : IFoo = CreateFooImpl() [Proxy(IBar)] _bar : IBar = CreateBarImpl() You would then have a fat object that is composed of little objects. http://ayende.com/2816/skinny-controller-fat-model#comment5http://ayende.com/2816/skinny-controller-fat-model#comment5Sun, 30 Sep 2007 23:00:01 GMT"Another approach is to use mixins in Ruby to separate the functionality into different files and mixed it into the User model. I don't really like it, but that is perhaps a matter of taste." Using mixins is an option (with AOP) in .NET as well. Why don't you like it? /Mats http://ayende.com/2816/skinny-controller-fat-model#comment4http://ayende.com/2816/skinny-controller-fat-model#comment4Sun, 30 Sep 2007 22:24:57 GMTFor that matter, let us take the example of IAuthorizationService, IAuthenticationSerivce and the User model that I have on the CLR. How would you structure them in Ruby? Take into account that there are at least two implementation of the services, for AD and hard coded. http://ayende.com/2816/skinny-controller-fat-model#comment3http://ayende.com/2816/skinny-controller-fat-model#comment3Sun, 30 Sep 2007 21:39:28 GMTThat is interesting, because the use of IoC bring a lot of dynamics to CLR projects. How do you handle that in Ruby projects? http://ayende.com/2816/skinny-controller-fat-model#comment2http://ayende.com/2816/skinny-controller-fat-model#comment2Sun, 30 Sep 2007 21:38:01 GMT> what happens when the model get too big? How do you break it up then? Same old way... sharpen the blade used to slice responsibilities, and slice them down to finer, related modules, be they classes, mixins, helpers, whatever. The difference from .NET would likely be the conspicuous absence of DI as a default means to compose aggregations. http://ayende.com/2816/skinny-controller-fat-model#comment1http://ayende.com/2816/skinny-controller-fat-model#comment1Sun, 30 Sep 2007 21:31:23 GMT