Hi Let me swing the pendulum back to the other side...
Repositories and the like sound good and clear and so on, well at least until you start to use them. I find the active record pattern with its static methods the most natural way to access data as objects. I had a problem when I started migrating to repositories: I wanted to actually use a rich object model, but I needed repositories at all places where I couldn't inject them. For example, in a software license management LOB application, I let the software figure out whether it has still a valid combination of required unused licenses. Since I didn't want to keep a list of license instance along with the software, I needed an license instance repository. But how to get one into the entity object? I ended up with a domain service which at the end is nothing but the undead transaction script zombied into object model, draining logic from it so that the model becomes anemic. In my previos ActiveRecord-model the method simply part of the software entity, looking up license instances with static methods and a query object in one case. After a while I became worried about my model becoming anemic and deleted the "repository_transition"-branch... I see the problem with testing, and I have an idea how to solve it, but I need more time to implement it. The idea is flashed here: http://groups.google.de/group/castle-project-devel/msg/cd70fa0a3140f689 If anyone is interested in helping, don't hesitate to contact me over this list. -Markus 2010/7/30 Patrick Steele <[email protected]>: > I'm in the process of migrating a medium-sized AR/MonoRail project > from the "ActiveRecord" pattern (using the static Find/FindAll/etc...) > to a repository pattern. It's a big task (and taking a long time > since it's a side project), but the app started small and now that > it's medium sized (and growing), I really need to have more automated > unit tests and those just aren't possible using the static methods. > I'm also moving away from inheriting from ActiveRecordBase<T> and > using the ActiveRecordMediator<T> in my repositories. > > Going forward, if I was starting a new project with ActiveRecord, I > would stick with the repository pattern and ActiveRecordMediator + > POCO's (Plain Old CLR Objects). It's cleaner and gives more > flexibility to your data architecture and makes testing/mocking much > easier. > > --- > Patrick Steele > http://weblogs.asp.net/psteele > > > > On Fri, Jul 30, 2010 at 8:06 AM, Paul Bijl <[email protected]> wrote: >> Hi, >> >> I'm writing this post because I'm getting pretty confused about a good >> way to use ActiveRecord in my projects. I've been using ActiveRecord >> for some time now in my projects, and I really like it. It's easy to >> use, frees me from writing all kinds of sql queries and allows me to >> rapidly start my projects. At the moment, I work alot with the Asp.Net >> MVC framework, which I also love. I think these two techniques are a >> fine combination. >> >> Lately however, I begin to experience some problems. As my projects >> grow in size, and my knowledge and experience expand, I began to think >> about the right way to use ActiveRecord, and how it should fit in my >> projects 'Architecture'. >> >> At the moment, when I create a project, I create a folder called >> Models, and I put all my ActiveRecord Model Classes in there (for >> example Order). From my MVC-controllers, I call the various static >> methods inside the Models to get objects from the db. (FindAll, >> FindOne, etc). Depending on my needs, I provide some Expressions to >> get specific data. When I got my data, I pass it on to my view, fairly >> simple. >> >> As some of you would point out, this isn't a best practice. I >> sometimes receive the infamous 'No Session' errors, so I began to use >> ViewModels. This all feels quite natural. >> >> The problem is that my current method doesn't feel good anymore. By >> accessing the AR Models directly from my controllers, it feels tightly >> coupled and it seems difficult to UnitTest. So I began to read about >> repositories, data access layers, data access objects and that kind of >> stuff, and I got pretty lost.. >> >> Somehow the use of a repository feel natural (its mockable/fakeable, >> and this way my program doesn't really know about my ORM, which makes >> it easy to change to another one), but after reading alot of articles, >> i'm not so sure anymore (like today I read some aricles by Ayende, >> saying this is really a YAGNI-point) >> >> So my question is really: how should I implement AR in my projects, >> and how do YOU implement it? Is it a good or bad practice my >> controllers 'know' about my ORM, should I use Interfaces and >> repositories? >> >> I know there isn't ONE answer to this, and I really know it all >> depends on the type of projects, but I really hope someone can shed >> some light on this problem, show me some examples and help me >> understand better. >> >> Kind regards, >> Paul >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Castle Project Users" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/castle-project-users?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/castle-project-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en.
