Loading ...
Sorry, an error occurred while loading the content.

[altdotnet] The correct definition of the repository pattern. /oldhorseflog

Expand Messages
  • mcintyre321
    I keep running into Repository classes which provide a facade over an ISession, allowing CRUD and querying ofr a particular type, but require a Flush method to
    Message 1 of 8 , Sep 1, 2009
    View Source
    • 0 Attachment
      I keep running into Repository classes which provide a facade over an
      ISession, allowing CRUD and querying ofr a particular type, but require a
      Flush method to be called.

      According to the P of EAA definition of Repository, the repo "Mediates
      between the domain and data mapping layers using a collection-like interface
      for accessing domain objects". i.e. it should act a bit like a collection.
      The version I keep running into needs a flush (unlike a collection), and
      because of this flush, you also can't swap the repo out for a web service or
      some other non-unit-of-work backed data store (which I thought was one of
      the reasons you might want to use a repo).

      Am I right about this being an incorrect implementation of Repository? If
      so, is it a de-facto pattern that I should learn to live with? Is it
      actually a good thing (I prefer to access a generic wrapper over the UoW and
      pass query objects but maybe I'm wrong). Please enlighten me, ALT.NETters!


      --
      View this message in context: http://www.nabble.com/The-correct-definition-of-the-repository-pattern.--oldhorseflog-tp25238014p25238014.html
      Sent from the ALT.NET Yahoo Group mailing list archive at Nabble.com.
    • Jesper De Temmerman
      ISession needs a flush, connections need a dispose.... Whatever it is you do you are going to need to dispose of some resources. What I usually do is have a
      Message 2 of 8 , Sep 1, 2009
      View Source
      • 0 Attachment
        ISession needs a flush, connections need a dispose.... Whatever it is you do you are going to need to dispose of some resources. What I usually do is have a RepositoryFactory that implements IDisposable. This factory provides the boundaries for the unit of work: everything that is done to a specific instance of the factory is considered part of one unit of work.

        The factory returns repositories (via an interface). These repositories can be managed by the factory: if they require a dispose the factory registers them internally and calls their dispose prior to it being disposed itself. This keeps the repositories' interface looking like a collection, but allows the actual implementation to manage resources.

        In your case, the repositoryfactory will create an ISession and pass this to every instance of the repository it creates. On dispose, the factory will dispose of the ISession after it was flushed. The repositories themselves do not need to be disposed, which I tend to prefer if possible.

        >
        > I keep running into Repository classes which provide a facade over an
        > ISession, allowing CRUD and querying ofr a particular type, but require a
        > Flush method to be called.
        >
        > According to the P of EAA definition of Repository, the repo "Mediates
        > between the domain and data mapping layers using a collection-like
        > interface
        > for accessing domain objects". i.e. it should act a bit like a collection.
        > The version I keep running into needs a flush (unlike a collection), and
        > because of this flush, you also can't swap the repo out for a web service
        > or
        > some other non-unit-of-work backed data store (which I thought was one of
        > the reasons you might want to use a repo).
        >
        > Am I right about this being an incorrect implementation of Repository? If
        > so, is it a de-facto pattern that I should learn to live with? Is it
        > actually a good thing (I prefer to access a generic wrapper over the UoW
        > and
        > pass query objects but maybe I'm wrong). Please enlighten me, ALT.NETters!
        >
        >
        > --
        > View this message in context:
        > http://www.nabble.com/The-correct-definition-of-the-repository-pattern.--oldhorseflog-tp25238014p25238014.html
        > Sent from the ALT.NET Yahoo Group mailing list archive at Nabble.com.
        >
        >


      • mcintyre321
        You ve slightly missed the point of what I was asking, that may well be my fault for not explaining myself properly. I think what you propose is a misuse of
        Message 3 of 8 , Sep 1, 2009
        View Source
        • 0 Attachment
          You've slightly missed the point of what I was asking, that may well be my
          fault for not explaining myself properly.

          I think what you propose is a misuse of the Repository pattern as defined by
          the DDD book and by Fowler because the requirement for flush/dispose means
          the Repo does NOT act like a collection, and as such it shouldn't be called
          a Repository.

          Even if I were happy with the Repos needing a Commit method, the shared
          ISession you have used means flushing one will flush them all.

          My question was

          1. am i wrong about the definition of the pattern (i.e. a Repo should act
          like a collecton)?
          2. if not, does the Repo as facade over session break the definition?
          3. if so, am I crazy to worry about this common misuse of the pattern?
          --
          View this message in context: http://www.nabble.com/The-correct-definition-of-the-repository-pattern.--oldhorseflog-tp25238014p25240480.html
          Sent from the ALT.NET Yahoo Group mailing list archive at Nabble.com.
        • Jesper De Temmerman
          What I take from the book is that a repository has an interface similar to a collection. What the internal mechanism of the repository is does not matter.
          Message 4 of 8 , Sep 1, 2009
          View Source
          • 0 Attachment
            What I take from the book is that a repository has an interface similar to a collection. What the internal mechanism of the repository is does not matter. Because a repository is interfaced it does not need any public methods that deal with the internal workings of the repository such as flush, commit, etc.

            >
            > You've slightly missed the point of what I was asking, that may well be my
            > fault for not explaining myself properly.
            >
            > I think what you propose is a misuse of the Repository pattern as defined
            > by
            > the DDD book and by Fowler because the requirement for flush/dispose means
            > the Repo does NOT act like a collection, and as such it shouldn't be
            > called
            > a Repository.
            >
            > Even if I were happy with the Repos needing a Commit method, the shared
            > ISession you have used means flushing one will flush them all.
            >
            > My question was
            >
            > 1. am i wrong about the definition of the pattern (i.e. a Repo should act
            > like a collecton)?
            > 2. if not, does the Repo as facade over session break the definition?
            > 3. if so, am I crazy to worry about this common misuse of the pattern?
            > --
            > View this message in context:
            > http://www.nabble.com/The-correct-definition-of-the-repository-pattern.--oldhorseflog-tp25238014p25240480.html
            > Sent from the ALT.NET Yahoo Group mailing list archive at Nabble.com.
            >
            >


          • Paul Batum
            I agree with Jesper - the interaction between the repository and its backing store (if it has one - a repository implementation used for unit testing probably
            Message 5 of 8 , Sep 1, 2009
            View Source
            • 0 Attachment
              I agree with Jesper - the interaction between the repository and its backing store (if it has one - a repository implementation used for unit testing probably won't) is an implementation detail. In the case of NHibernate, it will flush the session whenever necessary to ensure query coherency (see http://ayende.com/Blog/archive/2009/08/17/benchmark-cheating-a-how-to.aspx) so your repositories implemented on top of NH *will* have consistent collection-like behavior.

              Paul Batum

              On Wed, Sep 2, 2009 at 12:09 AM, Jesper De Temmerman <jesper@...> wrote:
               

              What I take from the book is that a repository has an interface similar to a collection. What the internal mechanism of the repository is does not matter. Because a repository is interfaced it does not need any public methods that deal with the internal workings of the repository such as flush, commit, etc.


              >
              > You've slightly missed the point of what I was asking, that may well be my
              > fault for not explaining myself properly.
              >
              > I think what you propose is a misuse of the Repository pattern as defined
              > by
              > the DDD book and by Fowler because the requirement for flush/dispose means
              > the Repo does NOT act like a collection, and as such it shouldn't be
              > called
              > a Repository.
              >
              > Even if I were happy with the Repos needing a Commit method, the shared
              > ISession you have used means flushing one will flush them all.
              >
              > My question was
              >
              > 1. am i wrong about the definition of the pattern (i.e. a Repo should act
              > like a collecton)?
              > 2. if not, does the Repo as facade over session break the definition?
              > 3. if so, am I crazy to worry about this common misuse of the pattern?
              > --
              > View this message in context:
              > http://www.nabble.com/The-correct-definition-of-the-repository-pattern.--oldhorseflog-tp25238014p25240480.html
              > Sent from the ALT.NET Yahoo Group mailing list archive at Nabble.com.
              >
              >



            • Michael D. Brown
              Exactly the Repository provides Collection-Like semantics for your Aggregate Root. However, there is nothing in the pattern that prevents backing the
              Message 6 of 8 , Sep 1, 2009
              View Source
              • 0 Attachment

                Exactly the Repository provides Collection-Like semantics for your Aggregate Root. However, there is nothing in the pattern that prevents backing the Repository with UoW semantics. In fact if you look at PEAA, the description explicitly says that it “Mediates between the domain and data mapping layers…” The pattern itself only dictates the what. The how is up to the implementor.

                 

                From: altdotnet@yahoogroups.com [mailto:altdotnet@yahoogroups.com] On Behalf Of Jesper De Temmerman
                Sent: Tuesday, September 01, 2009 10:09 AM
                To: altdotnet@yahoogroups.com
                Subject: Re: [altdotnet] The correct definition of the repository pattern. /oldhorseflog

                 

                 

                What I take from the book is that a repository has an interface similar to a collection. What the internal mechanism of the repository is does not matter. Because a repository is interfaced it does not need any public methods that deal with the internal workings of the repository such as flush, commit, etc.

                >
                > You've slightly missed the point of what I was asking, that may well be my
                > fault for not explaining myself properly.
                >
                > I think what you propose is a misuse of the Repository pattern as defined
                > by
                > the DDD book and by Fowler because the requirement for flush/dispose means
                > the Repo does NOT act like a collection, and as such it shouldn't be
                > called
                > a Repository.
                >
                > Even if I were happy with the Repos needing a Commit method, the shared
                > ISession you have used means flushing one will flush them all.
                >
                > My question was
                >
                > 1. am i wrong about the definition of the pattern (i.e. a Repo should act
                > like a collecton)?
                > 2. if not, does the Repo as facade over session break the definition?
                > 3. if so, am I crazy to worry about this common misuse of the pattern?
                > --
                > View this message in context:
                > http://www.nabble.com/The-correct-definition-of-the-repository-pattern.--oldhorseflog-tp25238014p25240480.html
                > Sent from the ALT.NET Yahoo Group mailing list archive at Nabble.com.
                >
                >

              • mcintyre321
                That is very cool - I didn t realise NH would auto flush. So the Repo s I keep coming across at work ARE wrong - they each have their own flush methods which
                Message 7 of 8 , Sep 1, 2009
                View Source
                • 0 Attachment
                  That is very cool - I didn't realise NH would auto flush.

                  So the Repo's I keep coming across at work ARE wrong - they each have their
                  own flush methods which aren't needed due to NH's magic, but also I'm wrong
                  - repos can work without needing a flush in the background as NH is so gosh
                  darn clever.

                  thanks!



                  Paul Batum wrote:
                  >
                  > In the case of NHibernate, it
                  > will flush the session whenever necessary to ensure query coherency ..
                  > so your repositories implemented on top of NH *will* have consistent
                  > collection-like behavior.
                  >
                  >

                  --
                  View this message in context: http://www.nabble.com/The-correct-definition-of-the-repository-pattern.--oldhorseflog-tp25238014p25243214.html
                  Sent from the ALT.NET Yahoo Group mailing list archive at Nabble.com.
                • Richard Dingwall
                  ... Btw -- even if your ORM doesn t auto flush (in NHibernate this is configurable), the flushing should be once at the end of the unit of work/transaction and
                  Message 8 of 8 , Sep 1, 2009
                  View Source
                  • 0 Attachment
                    On Wed, Sep 2, 2009 at 4:10 AM, mcintyre321<mcintyre321@...> wrote:
                    >
                    >
                    > That is very cool - I didn't realise NH would auto flush.
                    >
                    > So the Repo's I keep coming across at work ARE wrong - they each have their
                    > own flush methods which aren't needed due to NH's magic, but also I'm wrong
                    > - repos can work without needing a flush in the background as NH is so gosh
                    > darn clever.
                    >

                    Btw -- even if your ORM doesn't auto flush (in NHibernate this is
                    configurable), the flushing should be once at the end of the unit of
                    work/transaction and include everything, no matter which repository it
                    came from.

                    Having to explicitly flush each repository one after another could
                    become very confusing!!

                    --
                    Richard Dingwall
                    http://richarddingwall.name
                  Your message has been successfully submitted and would be delivered to recipients shortly.