Hey João 2009/6/17 João Bragança <[email protected]>
> > On Jun 17, 8:09 am, Craig Neuwirt <[email protected]> wrote: > > 2009/6/17 João Bragança <[email protected]> > > > > > > > > > Have you looked at InterLinq? It is a way of serializing linq queries. > > > Instead of exposing a bunch of ugly repository methods, you only have > > > to expose Query of T. You can use an interceptor to fake the generic > > > method on the client proxy: > > > > No I haven't but it sounds interesting. How does it deal with > serializing > > domain entities from query? > > > http://www.codeplex.com/interlinq > > It doesn't. All it is responsible for is turning a linq query into > something serializable. I decorated all my entities with > [DataContract]. But that doesn't work on nhibernate proxies if it is > not on both sides of the wire! > In fact, this is one of the issues I had with it.. I didn't want > (foolishly) the client to know about nhibernate. I ended up writing an > interceptor that recursively hydrated the object graph at once since > nhibernate doesn't seem to have this. It ended up causing performance > problems - grabbing way more than was needed - unnecessarily which is > why I scrapped it. I still have the code in my svn if you want to take > a look. Warning, it will burn your eyes! Sure, anything with an interceptor must be a good read. I'll make sure to wear my sun glasses. thanks, craig > > > > > > > > > [OperationContract] > > > IQueryable RealQuery(string typeName) > > > > > IQueryable[of T] Query[of T]() > > > > > I went this way in my current project... I ended up scrapping it > > > because I had no need for n tier with wcf. > > > > > On Jun 17, 5:08 am, Craig Neuwirt <[email protected]> wrote: > > > > Thanks for all of your feedback. It's been very helpful. > Currently, > > > there > > > > is no performance issue with respect to data access. I am a big fan > of > > > > databinding to domain model, but the client wants to remove all > access to > > > > the db in the DMZ. Messaging will certainly replace the workflow > aspects > > > of > > > > the app so I was trying to minimize the types of communication from > the > > > app > > > > layer. I agree messaging is not really optimal for data querying,but > I > > > so > > > > don't look forward to having to define a bunch of data contracts to > > > > represent the query results. > > > > Thanks again, > > > > craig > > > > > > On Wed, Jun 17, 2009 at 2:37 AM, rg <[email protected]> > wrote: > > > > > > > Craig, I would think twice about replacing synchronous > communication > > > > > between web frontend and backend with async messaging. Probably > this > > > > > will lead to major redesign of the system, besides you will have to > > > > > store local state somewhere in the web application (because > messages > > > > > arrive asynchronously) and use polling at the client (javascript?) > to > > > > > detect state changes. What good will it do to the application? For > > > > > sure it will complicate the web application and the browser > javascript > > > > > code, it also might improve overall performance (or decrease it as > > > > > well) - of course if there was any performance problem at first. If > > > > > performance is the issue you should do some profiling to spot the > > > > > problem - probably the database access is the slowest and least > > > > > scalable part of the system, so using async messaging in the layers > > > > > above db will not change anything in query performance. > > > > > Rafal > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" 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/rhino-tools-dev?hl=en -~----------~----~----~----~------~----~------~--~---
