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! > > > > [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 -~----------~----~----~----~------~----~------~--~---
