That makes sense.  I guess I was hoping for too much from
ActiveRecord.

So my best bet is to handle some functionality with some special
queries, instead of just using the ActiveRecord properties on the
models.  The Repository pattern is the best place to house some of
those queries, but that's just the best place to do it for
maintainability and cleanliness -- it's not the actual solution.

Thank you for your patience with me.  Every time I feel like I've
started to get a handle on how to do things, something happens that
shows me I still have so much to learn.

On Sep 11, 4:24 pm, William Chang <[email protected]> wrote:
> Yes
>
> The ActiveRecord pattern does provide basic CRUD methods (e.g. Find(),
> FindAll() methods). But, I use the Repository pattern as well because
> of the complexity of the web application. Thus, I need another
> separation in my DAL. The repository interact between your model/
> database layers and your business-logic/view layers. The repository
> (interface) contains methods and the methods contains queries.
>
> Sincerely,
> William Changhttp://www.williamchang.orghttp://www.babybluebox.com
>
> On Sep 11, 4:40 pm, JakeS <[email protected]> wrote:
>
> > It's obvious I'm not using ActiveRecord the "right" way for several
> > things, and it's scary that despite reading the documentation as
> > thoroughly as possible I still don't quite understand.  I appreciate
> > your patience in helping me figure things out.
>
> > I've read up on the Repository pattern and understand that it allows
> > you to abstract-away the interface to your data -- so instead of
> > having to figure out how to call each data model itself you instead
> > call a common interface for saving, updating, and deleting that data.
> > What I don't see is how that would help with my particular situation.
> > I can understand how it would be good for mocking and unit testing,
> > but how will it improve my actual data access, especially when
> > aggregating data across multiple models?
>
> > Do you mean I could write a repository for category items and write
> > queries to handle counting and fetching items by hand (in a more
> > efficient manner), rather than relying on the property on the model to
> > get this information?
>
> > On Sep 11, 2:44 pm, William Chang <[email protected]> wrote:
>
> > > If you decide to use the repository pattern, then you need two sets
> > > (or namespaces) of classes: Models and Repositories. The ActiveRecord
> > > mapping will be in the Models set. Repository is should not be a model
> > > of your database and it should contain methods (combination actions
> > > and events to do CRUD).
>
> > > Please Google more about repository pattern to learn more.
>
> > > Sincerely,
> > > William Chang
>
> > > On Sep 11, 3:17 pm, JakeS <[email protected]> wrote:
>
> > > > Thank you for the advice, but I'm still unsure exactly how to proceed,
> > > > partly because if my inexperience with using the repository pattern.
> > > > How will that help me here?
>
> > > > If I make a CategoryItem Repository, won't that still have make all
> > > > these database calls?  Or is this just a method of caching all that
> > > > data in memory so it only has to fetch it all the first time?
>
> > > > Thanks again for the help.
>
> > > > On Sep 11, 11:38 am, William Chang <[email protected]> wrote:
>
> > > > > Even though, I don't have a solution for you...
>
> > > > > From looking at your code snippet, I think your implementation of
> > > > > ActiveRecord for ICategoryItem is unnatural (neither popular pattern
> > > > > of ActiveRecord or Repository). Instead of using interface directly on
> > > > > the model (an object that represent a table), it should be an
> > > > > interface on the Repository classes.
>
> > > > > Sincerely,
> > > > > William Chang
>
> > > > > On Sep 11, 11:43 am, JakeS <[email protected]> wrote:
>
> > > > > > I have a system where categories can be assigned to multiple objects
> > > > > > (such as a Calendar Event or an Action Item) within the system.  
> > > > > > Each
> > > > > > of those objects shares an Interface -- ICategoryItem.  Then in the
> > > > > > category I have mapped it like this:
>
> > > > > > private IList<ICategoryItem> _items;
> > > > > > [HasManyToAny(typeof(ICategoryItem), "CategoryID", "CategoryItems",
> > > > > > typeof(int),
> > > > > >     "TypeOfItem", "Item_ID", MetaType = typeof(string), Lazy = 
> > > > > > true)]
> > > > > > [Any.MetaValue("ACTIONITEM", typeof(ActionItem))]
> > > > > > [Any.MetaValue("DISCUSSION", typeof(Discussion))]
> > > > > > [Any.MetaValue("EVENT", typeof(CalendarEvent))]
> > > > > > [Any.MetaValue("LIBRARYOBJECT", typeof(LibraryObject))]
> > > > > > [Any.MetaValue("WHITEBOARD", typeof(WhiteBoard))]
> > > > > > public IList<ICategoryItem> Items
> > > > > > {
> > > > > >     get
> > > > > >     {
> > > > > >         if (_items == null) { _items = new List<ICategoryItem>(); }
> > > > > >         return _items;
> > > > > >     }
> > > > > >     set
> > > > > >     {
> > > > > >         _items = value;
> > > > > >     }
>
> > > > > > }
>
> > > > > > This works pretty well, but every time the category.Items is 
> > > > > > accessed
> > > > > > it fires off a LOT of queries--
> > > > > > Select ... FROM CategoryItems
> > > > > > Select ... From Discussion
> > > > > > Select ... From Discussion
> > > > > > Select ... From Discussion
> > > > > > and so on.
>
> > > > > > Can anyone offer any advice on improving this?  Is there a simple
> > > > > > solution, or should I just break this relationship alltogether and
> > > > > > have the items be a list of basic object information, then use that 
> > > > > > to
> > > > > > find the real object later if needed?
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to