This somewhat depends on the amount of parameters and their datatypes.
Basically when you pass and object reference you're not spending extra memory, so if you object ever existed anyway and isn't too tightly tied to your data structure (which could cause copying to loose that,) passing the object is more efficient.
The border case is when the parameters being passed are reference types anyway, but with value types you'll be copying them
https://msdn.microsoft.com/en-us/library/9t0za5es.aspx
unless of cause you're using ref keywords which is also not very sexy.
Generally the debate can revolve around the principle of immutable data objects started off with an excellent series by Eric Lippert
http://blogs.msdn.com/b/ericlippert/archive/2007/11/13/immutability-in-c-part-one-kinds-of-immutability.aspx quite a while ago.
Point being that though Generally objects are fine as parameters, when methods working on objects modify them, they in turn are nolonger immutable, which can make coding less transparent.
Something i at large ignore (but acknowlege) myself.
My personal perference goes towards that when moving towards data storage i tend to move towards parameters, as especially with early days EF in play, you'll anyway have to read the entity from database to update it. Inversely moving from data to other layers the move is to establish your data carrier object og dispach it from data layer somewhere after having instantiated it from your data interacting type.
With EF from a certain version we get Detachability, but that often still takes some doing.
https://msdn.microsoft.com/en-us/library/vstudio/bb896271(v=vs.100).aspx
and
https://msdn.microsoft.com/en-us/library/vstudio/bb738697(v=vs.100).aspx