I have an object that has about 50 properties, but one of my methods only uses about 3 of these properties. Is it still better to pass the whole object or parts. A scenario would be were I am using Dapper to query a database to map data into a POCO object, but I only need a few of the properties, so I am faced with these two scenarios:
var car = db.Query<Car>("SELECT * FROM Car Where Id = @Id", new {Id}).FirstOrDefault();
Process(car);
Or
var car = db.Query<car>("SELECT VIN, Year, Color FROM Car Where Id = @Id", new {Id}).FirstOrDefault();
Process(car.VIN, car.Year, car.Color);
In the above case, does the fact that I am using Dapper matter? I know the less properties it has to map to the less time it takes. But at the same time, by only bringing back a set of properties, if I ever need something else, I will have to modify the query or add a new method to bring back what I want.
I have an object that has about 50 properties,
Stop! Go – right now – and fix this.
Of course you’re going to run into functions that only use part of your object, when your object is doing everything under the sun. No object needs 50 independent properties. Certainly some of them can be organized into sub-objects. Those three that your function takes are a good candidate set.
should I pass the whole object to a function or just parts?
In the more general case, it depends. Best practices say to pass in just what you need. Best practices also say to code to an interface (in this case, the signature of the method). So this is one of those cases where you need to weigh the two best practices against the likelihood that they will come into play.
Does the method make sense to take the whole thing (since you might use other parts later)? Does the method make sense to the parts and not care that they are from independent sources?
And the other consideration is similar to the above advice: if you often find yourself taking bits from an object, it is a sign that those bits are their own cohesive object. Consider making them their own sub-object, or otherwise divvying up responsibilities to better align with how you’re actually using the stuff.
Also, this answer is specifically about functions. If you’re working across communication boundaries, you will often want to/need to cut down your data size. Sending 50 fields across the wire when you only need 3 is more troublesome there.
4
It sounds like you have a good grasp of the issues involved. I don’t know specifically whether Dapper makes a difference in your strategy, but in general you only want to return the data from the database that you need.
Will you have to alter your query if you need another property in the future? Of course, and that’s the downside of returning only what you need. Whether excluding the unused data makes a difference in your application depends largely on scale. At web scale, companies like Twitter, Facebook, and Google go to great lengths to optimize everything, and excluding unused data from a query is a standard optimization.
As for the Process() call, you are better off passing the car object:
Process(car);
but you need to be able to do that with the optimized query:
var car = db.Query<car>("SELECT VIN, Year, Color FROM Car Where Id = @Id", new {Id}).FirstOrDefault();
Then your method signature doesn’t need to change. When you need a new property, you just add it to the query string.
Send the object instead of the property! I’d rater change which field to use in the callee than having to change 100 calls to the method. Broken properties is not a problem if the code is used and tested all the time. If you send data over a communications channel you may have to make other considerations.
Pass a whole object, but, select from databse only that fields that you eally need. You will get object with three filled properties, and others properties will get defaults. Such way it will be simplier to fill other properties with data just by adding field name to query, without changing method’s signature.
4