Comments on: Why On Earth Would A Developer Do This?

By: Clean Code Versus Great Code

Clean Code Versus Great Code — Thu, 21 Jul 2011 16:01:48 +0000

[...] A lot of people love to talk the talk when it comes to writing clean code. They'll stress their dedication to it, in some cases even wearing Uncle Bob's green band while coding so they'll never lose sight of what's incredibly important to them: writing clean code. Unfortunately, i've noticed on numerous occasions that many of these people don't always put as much emphasis on what the code is doing compared to how it looks. Sometimes they don't really bother to learn what their ORM is doing behind the scenes. Or they'll prefer to use something like Automapper to map entities to DTO's even though it is woefully inefficient compared to simply retrieving projected data. They don't always think about the cost of multiple remote calls or sending way too much data over the wire. And when they're not perfecting the art of writing bowling games over and over again, they just might hit the database in loop. [...]

By: Mai Kalange

Mai Kalange — Fri, 12 Dec 2008 18:30:22 +0000

I guess it adds weight to the maxim…”Refactor mercilessly”

By: Davy Brion

Davy Brion — Tue, 09 Dec 2008 09:30:40 +0000

hmm… apples and oranges

criticizing code in a blog post and working with teammates are two entirely different things. for starters, when one of my teammates writes code that needs improvements, i explain them what’s wrong with it and how we can improve it. There’s no criticizing going on there.

By: Peter

Peter — Tue, 09 Dec 2008 08:49:49 +0000

Having read your post on a great technical lead, I doubt I would ever wish to work under you, with your criticising and your to-the-heart laments. I respect you say in your technical lead blog you do try to aspire to those values you present. I think you just have a long way to go.

Peter.

By: Jonathan Rockway

Jonathan Rockway — Sun, 07 Dec 2008 06:33:48 +0000

Where exactly does the code say that it is connecting to a relational database? How do we know that the PayrollDatabase is not an in-memory structure? If it is connecting to a relational database, how do we know that the query is not done at the “PayrollDatabase.GetAllEmployeeIds()” call and then the results cached for the scope of the executing block?

Basically, you are assuming a particular implementation of the PayrollDatabase, and are criticizing that implementation. I have worked on many projects where the ORM is smart enough to optimize cases like this, or where the data is already in memory, and I only “pay” for the method call. (The only thing I would change is to remove the part where we get the IDs, and instead get an iterator over the objects. If you want to criticize an API that exposes arbitrary IDs, I am fine with that.)

By: Cristian

Cristian — Sat, 06 Dec 2008 15:15:31 +0000

That code is stupid, with or without a database. What’s the point in getting all the IDs and then the object for each ID, when you could iterate over the whole collection using a foreach statement? This is what I would call a proper abstraction.

By: daniel fernandes

daniel fernandes — Fri, 05 Dec 2008 08:12:58 +0000

Frederik Gheysels:
I don’t see why you can’t create a specialized entity, call it a DTO, that shares some of the implementation of Employee but this time mapped as Davy said to a View.
Using full blown Entities for batch processing is fine for small jobs but that just doesn’t scale. Using a “DTO” would allow to use the same infrastructure as with the Entities but would provide tremendous performance benefits.
Daniel

By: Davy Brion

Davy Brion — Wed, 26 Nov 2008 19:17:15 +0000

in that case i’d probably try to get it working without the paging at first. then i’d test it it with a very large set of data to make sure i really do need to use paging. How many products are we talking about?

If paging really is necessary, a good solution to this problem is something that’s probably gonna require a bit of experimentation… i can’t just think of something that would definitely be great for this situation… sorry

By: Frederik Gheysels

Frederik Gheysels — Wed, 26 Nov 2008 16:25:53 +0000

Well, that’s just what I was trying to say: you cannot use a DTO, since determining the price that has to be exported, is a quite complex task which cannot be handled by SQL.
So, you’ll need to retrieve all the prices of a product, so that you can use the ‘DeterminePrice( params )’ member method of the Product class …
That’s the reason why you cannot use a DTO.

Therefore, what solution would you use in this particular case ?

I’m trying to create a ‘PagedResults’ class, which is given an ICriteria.
The PagedResults class would then use the SetFirstResults & SetMaxResults methods to retrieve the required entities in ‘chunks’. But, then I am faced with the problems I’ve described in my earlier comment.
So, I’ve decided to modify my ‘PagedResults’ class a bit, so that I first retrieve the next ‘n’ Id’s, and then I let NHIbernate retrieve the entities for those Id’s (in one go), but this is a bit problematic as well …

By: Davy Brion

Davy Brion — Wed, 26 Nov 2008 15:34:59 +0000

why wouldn’t i use a DTO for this? it appears to be the most optimal solution… you could map the DTO to a view which retrieves the correct data and that would be all there is to it. If you want to use paging on that view, there’s no problem either…

By: Frederik Gheysels

Frederik Gheysels — Wed, 26 Nov 2008 15:11:41 +0000

Hmm, how would you handle this situation:

Suppose you’ve an entity that is mapped against multiple tables. In other words, the entity has a number of collections which contain related information.
For instance, you have a class ‘Product’, which has a collection of ‘Prices’, and a collection of ‘Names’ (for every language, a different name), etc…

You need to write the Product information to a file, and this file contains, for each product, the price that is currently valid, and the ProductName for a specific language.
(You cannot use a DTO to retrieve the Products ).

If you use the ‘paging’ capabilities of NHibernate, NHibernate will issue several SELECT statements, which retrieve a recordset of n rows (where n is the ‘page-size’ that you’ve specified).
However, this recordset of n rows maybe contains information for n / 2 entities:
Since the entity has a collection of Names and Prices, the recordset contains a row for every Product/ProductName/ProductPrice.
This means that, if a product has 2 names and 3 prices, the recordset will contain 2*3 records for one Product.
Then, the pages will contain fewer entities then you’ve specified.

How would you solve this ?
One could argue that the Names and Prices should be loaded lazily, but, when you do that, you’ll find yourself in the same situation as the piece of code you’ve posted:
multiple queries will be fired in the loop where you iterate over every Product that you’ve loaded …

By: Davy Brion

Davy Brion — Wed, 26 Nov 2008 12:30:30 +0000

This really isn’t just a case of premature optimization… but going to the database in a loop is about the dumbest thing you can do.

and again, as far as the readability is concerned, i’ll just copy/paste something from one of the earlier comments:

“how is the above code cleaner, simpler and more readable than simply looping through the return value of PayrollDatabase.GetAllEmployees?”

By: Angel

Angel — Wed, 26 Nov 2008 12:26:13 +0000

Optimize later:

Using an ORM-like approach is a good thing, code is read much more times that it get’s writed, and if the performance of the program is Ok I don’t see a reason why “optimize” it. The question here is: Is it worth to optimize the code to make just one SQL query instead of six?

Premature optimization is the most common cause of project failures.

By: Davy Brion

Davy Brion — Tue, 25 Nov 2008 17:01:37 +0000

like i said earlier, if it was a simple comparison then i’d put it in the where clause as well… if the check is more complex, then i’d rather keep that logic outside of the queries as well

By: Mwanji Ezana

Mwanji Ezana — Tue, 25 Nov 2008 16:29:10 +0000

“btw, how is the above code cleaner, simpler and more readable than simply looping through the return value of PayrollDatabase.GetAllEmployees?”

If we’re only interested in the employees whose pay date is today, why pull all the employees out of the DB? A simple where clause would return only the employees of interest, shifting computation to the most optimised place (the DB server) and generating a much smaller set to loop over.

By: Ray Bird

Ray Bird — Tue, 25 Nov 2008 16:25:35 +0000

Yup, see ya in the soup line!

By: Davy Brion

Davy Brion — Tue, 25 Nov 2008 16:13:59 +0000

so those petty insults kinda look stupid now huh? :p

By: Ray Bird

Ray Bird — Tue, 25 Nov 2008 16:10:11 +0000

True, you got me there.

By: Davy Brion

Davy Brion — Tue, 25 Nov 2008 16:08:16 +0000

I fully agree that caching is the responsibility of the datalayer… that doesn’t give developers a pass for writing really shitty code though

btw, how is the above code cleaner, simpler and more readable than simply looping through the return value of PayrollDatabase.GetAllEmployees?

By: Ray Bird

Ray Bird — Tue, 25 Nov 2008 16:03:46 +0000

Developers do this because they don’t know its a database. If you are correctly using abstractions and coding to an interface, then you don’t know what’s in the black box. So you do what any good programmer would do, write the simplest, cleanest, most readable code. Caching is your data layers problem. Since good programmers write clean readable code whenever we can, we can deduce that you must suck and are one of the pointy hair grumbles that have been screwing up IT since day one. Good luck with your next career.