Nice, I am willing to see it a work. On Fri, Nov 21, 2008 at 6:27 PM, Chad Myers <[EMAIL PROTECTED]> wrote:
> Yeah, the transaction stuff inside the repository isn't very good. We > have since switched to a more formal unit of work pattern at work. > > > > The stuff in the "Framework" assembly for Fluent NHibernate has fallen into > serious disrepair and neglect, unfortunately L > > > > -c > > > > *From:* [email protected] [mailto: > [EMAIL PROTECTED] *On Behalf Of *Guido Ziliotti > *Sent:* Friday, November 21, 2008 11:21 AM > *To:* [email protected] > *Subject:* [fluent-nhib] Re: IRepository, why Entity conswtraint is there? > > > > I see...Anyway what about > > > > public void Delete<T>(T target){ > > withinTransaction(() => _session.Delete(target)); > > } > > > > ? Though a nice syntax, it's not reasonable to handle transactions inside > the repository. > > > > Thanks for your comments and infos. > > > > P.S. despite the phone you can't beat my one typo per word rate. > > On Fri, Nov 21, 2008 at 3:22 PM, Chad Myers <[EMAIL PROTECTED]> wrote: > > > IRepo is there from the early days when fluent nhib was just getting > started from the base code Jeremy and I had come up with. > > We used a conventional, opinionated approach to our repo (i.e. Domain-layer > super type, longs for primary keys, etc). > > I recommend that you copy the repo code and change the constraints and > change long to Guid or whatever you use rather than making IRepository more > generic. > > I actually did a spike to make IRepo more generic and, while it is > possible, the result was very poor and using the repo annoying due to the > extra noise plus losing some functioanlity by having the strong opinion that > all our ID's are of type X where X is long, guid, etc. > > > > > ---------------------- > Sent from my phone. Please excuse typos and extra characters > > > -----Original Message----- > From: Guido Ziliotti <[EMAIL PROTECTED]> > Sent: Friday, November 21, 2008 4:31 AM > To: [email protected] <[email protected] > > > Subject: [fluent-nhib] IRepository, why Entity conswtraint is there? > > I don't see any good reason for the constarint and the signature > > public interface IRepository{ > T Find<T>(long id) where T : Entity;//THIS IS THE DUBIOUS CONSTRAINT, > also long is a bit doubious > > void Delete<T>(T target); > T[] Query<T>(Expression<Func<T, bool>> where); > T FindBy<T, U>(Expression<Func<T, U>> expression, U search) where T : > class; > T FindBy<T>(Expression<Func<T, bool>> where); > void Save<T>(T target); > } > > First of all it semms unmotivated. Moreover It makes FInd tied to Entity > and > that seems quite a bad idea. > I think tha the class > > public class Repository:IRepository{/*...*/} > > is siiting there to be used for implementing concrete repositories. But > then > > T Find<T,K>(K id); > > would be a better signature. Especially bescose it removes the constrint > about T. > > Even if infrastucural- Entity is there to be inherited from and IMHO nobody > hould be happy to inherit form > any class because of the resulting dependecy in my domain objects. On the > other and possibly everybody > would be happy to have aworking implementation of IRepository to use for > implementing his own dedicated > repository. > > Best Regards, > Guido. > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Fluent NHibernate" 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/fluent-nhibernate?hl=en -~----------~----~----~----~------~----~------~--~---
