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();



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.

4 Answers 4


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.

  • exactly my reaction. Apr 1, 2015 at 2:07
  • I do agree with your answer, however, in this particular case, I have one scenario where I do use all the properties. This is something I can't change. I do however have methods that only use a few of these properties, so is it better to just get what I need or just get everything? Maybe I am going about this wrong, but I think that if I get everything I just need one method and I can just call that same method for any information or I will end up with multiple methods.
    – xaisoft
    Apr 1, 2015 at 13:12
  • 1
    @xaisoft - even if you need 50 properties (doubtful!), you don't need 50 properties in a single object.
    – Telastyn
    Apr 1, 2015 at 13:23
  • I have one scenario where I do use all the properties. Does not invalidate the answer. Use composition. Design first, code second. Strictly apply single responsibility principle; SRP says nothing regarding class size. I have a class with 3 properties and 1 method. S.R.P. QED.
    – radarbob
    Nov 3, 2015 at 23:32

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:


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.

  • 5
    Having 47 broken/invalid/garbage properties is shoddy, fragile coding.
    – Telastyn
    Apr 1, 2015 at 2:11
  • I'am talking about the case where he really needs that object with 50 properties. And, in my opinion, OOP gives us constructors, so we can build objects with defaults. Default value != broken value. If he need only 3 properties, there is nothing wrong to select only 3 properties from database. But he must be carefull not to send that object to methods that are expecting full filled object. Apr 1, 2015 at 2:16
  • 2
    But he must be carefull not to send that object to methods that are expecting full filled object. - Which is a huge problem, akin to the Liskov Substitution Principle. Suddenly only some instances of foo can be used with some functions that take foo. It's a buggy, unmaintainable mess.
    – Telastyn
    Apr 1, 2015 at 11:41
  • This is another problem. He asked about sending object vs properties. I answered his question. I'am agree with you that he has another design problems. Apr 1, 2015 at 11:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.