Ayende @ Rahien

gregmac commented on Taking a look at S#arp Lite– The MVC parts

Thu, 08 Mar 2012 19:15:20 GMT

I agree with @DemisBellot here. Using POCO (rather than EF/NH/whatever entities) absolutely prevents N+1 and also forces you to think about data access. Too many people use NH or EF without understanding how they work (and there is a lot to understand), and as a result their code is full of lazy loads and other dumb queries. Both good and bad, in a small app with low traffic/small DB, this doesn't really matter much. As it grows, this starts to matter a lot. I have a data access "abstraction" I guess (in that I put my data access code in one place, usually its own project to enforce low coupling and awareness of the API surface area if nothing else), and then build a simple API to expose the data operations I need, which all interact using POCO objects. As the db schema evolves or I want to enforce rules on top, there is one place to do that. I definitely don't want to see WHERE-type clauses in front-end application code. If the app has a lot of business rules, then there is another layer between app and data access to handle that, though really I am less fussed with if "business rules" exist in the DB (stored procs/triggers), data access (WHERE logic) or code layer, than that they do NOT exist in front-end. This is especially when there are multiple parts of the UI or other apps (web API, scheduled tasks daemon, etc) that do the same interactions.

Dmitry commented on Taking a look at S#arp Lite– The MVC parts

Wed, 07 Mar 2012 22:48:33 GMT

Is there anything in the framework that actually simplifies development? In all the posts I have not seen anything that saves or improves code that I could write using NHibernate and Automapper directly.

Karep commented on Taking a look at S#arp Lite– The MVC parts

Wed, 07 Mar 2012 20:28:57 GMT

Oh c'mon! Author is creating a framework and he doesn't even know what SELECT N + 1 is!? I think I have to create my own framework soon.

Kiliman commented on Taking a look at S#arp Lite– The MVC parts

Wed, 07 Mar 2012 18:44:13 GMT

@Tungano, Great quote! "I see little value in these 'color between the lines' projects. The architecture's value lays in dealing with the incompetent who perhaps shouldn't be touching your codebase to begin with. I prefer working with people who can draw."

Rajeesh commented on Taking a look at S#arp Lite– The MVC parts

Wed, 07 Mar 2012 16:49:30 GMT

Thanks ayende. I have been explain about this issue to my friend couple of days back. My suggestion was to flatten the model to simple plain view model depending on the scenario. So that view won't be generating the database queries. I will refer this post him.

Mohamed RAHIM commented on Taking a look at S#arp Lite– The MVC parts

Wed, 07 Mar 2012 15:37:36 GMT

NH FetchMany Or EF Include is the only way!

Felice Pollano commented on Taking a look at S#arp Lite– The MVC parts

Wed, 07 Mar 2012 14:59:49 GMT

I don't know if it is just left apart in the example, but the GetAll() has no parameters for limiting the result set. That is something thet makes me always angry;)

Tungano commented on Taking a look at S#arp Lite– The MVC parts

Wed, 07 Mar 2012 14:13:21 GMT

correction: IEnumerable of type string ...it ate my angle brackets

Tungano commented on Taking a look at S#arp Lite– The MVC parts

Wed, 07 Mar 2012 14:11:59 GMT

I don't like passing domain objects to views. For each view I create a 'view model' where I either expand or flatten some data. A view model would in this case have a categories collection that if of type IEnumerable since that is all what the view is rendering. I let the controller project data on the 'view model'. I prefer to not have IQueryable on repositories, avoid All() if possible. In some cases you grab a bit too much data only to filter it out in-memory. If performance suffers I could create a specialized more performant query somewhere. But then again if I am tailoring for the incompetent: they would not call it would they? I see little value in these 'color between the lines' projects. The architecture's value lays in dealing with the incompetent who perhaps shouldn't be touching your codebase to begin with. I prefer working with people who can draw.

magellings commented on Taking a look at S#arp Lite– The MVC parts

Wed, 07 Mar 2012 14:02:06 GMT

HasMany(x => x.Children).AsSet().SetAttribute("batch-size", "20") ???

Ayende Rahien commented on Taking a look at S#arp Lite– The MVC parts

Wed, 07 Mar 2012 13:56:22 GMT

magellings, Oh, I can do that, and have this happen _everywhere_ ? That seems to be too drastic a step

Demis Bellot commented on Taking a look at S#arp Lite– The MVC parts

Wed, 07 Mar 2012 13:55:13 GMT

@JasonMeckley Yes using a Micro ORM like OrmLite does help prevent this as you're only returning POCO models (i.e. not IQueryables/ORM DCs/etc that supports additional querying) so everything needs to be pre-fetched in the repository before hand making it impossible to perform an N+1 query outside of the repository. Micro ORMs remove the "hidden abstraction" you get with Heavy ORMs and what you're left with is very much a "whay you query" is "what you get".

magellings commented on Taking a look at S#arp Lite– The MVC parts

Wed, 07 Mar 2012 13:54:03 GMT

Can't you just set batch mode for selects on in your session factory configuration? All in all so far, I am liking the original S#arp better than Lite.

Rémi BOURGAREL commented on Taking a look at S#arp Lite– The MVC parts

Wed, 07 Mar 2012 12:52:15 GMT

The problem with this war against repository is that you consider querying the database is neither the view or the model. I don't like repository either because the way you're creating your linq query after GetAll() will change depending on the ORM (for instance some Linq integration will handle the Contains, and some not). But I always create a "ProductDataSource" with a "IEnumerable Get(ProductFilter filter)" method (I don't think it's a repository), and if I need to I create a ProductOutputFilter that'll say if I need to load the Categories or not. ORM switching is not a legend, It's interesting to be able to switch when you want to try something new (with my method I recently moved from plain SQL to NH) or to leave an abandoned framework.

Dooh commented on Taking a look at S#arp Lite– The MVC parts

Wed, 07 Mar 2012 12:12:12 GMT

It's just one of many problems that repositories are producing for sake of advantage of the "easy" ORM switching.

morcs commented on Taking a look at S#arp Lite– The MVC parts

Wed, 07 Mar 2012 11:44:51 GMT

@Mark or FetchMany as Ayende points out, but it's the fact that a developer likely won't even be aware of the N + 1 problem that he's raising, I think!

Jason Meckley commented on Taking a look at S#arp Lite– The MVC parts

Wed, 07 Mar 2012 11:43:41 GMT

@Thomasz ormlite won't change anything in this case becuase you still have the repository abstraction.

Mark Adamson commented on Taking a look at S#arp Lite– The MVC parts

Wed, 07 Mar 2012 11:29:05 GMT

I may be missing the point. Could this be easily fixed with a .Include(p => p.Categories) appended on to the controller query. That would force it to download the categories in the original select... I think

Tomasz Kubacki commented on Taking a look at S#arp Lite– The MVC parts

Wed, 07 Mar 2012 10:28:58 GMT

All we need to avoid n+1 is .... simpler ORM to make query per view. Can be done easier with any any micro-orm ServiceStack.OrmLite or Massive using raw SQL (which is much widely known and easier to understand than NH or EF magic).

Phillip commented on Taking a look at S#arp Lite– The MVC parts

Wed, 07 Mar 2012 10:21:45 GMT

When it comes to C#, I find code formatted like that hard to read. (my opinion)