I’m writing a solution where the data entities are passed to clients using datasets through a WCF service, with nHibernate as ORM.
My predecessor has written some translator classes, converting datasets to entities and vice versa. In most cases he’s declared the return object as a parameter for the object.
For example:
Public Shared Function CreateEntity(ByVal ds As DataSetObject, ByVal entity As EntityObject) As EntityObject
Dim row As ds.EntityObjectRow = ds.EntityObject(0)
entity.Id = row.Id
// Etc.
Return entity
End Function
While I want to do it like:
Public Shared Function CreateEntity(ByVal ds As DataSetObject) As EntityObject
Dim row As ds.EntityObjectRow = ds.EntityObject(0)
Dim entity As New EntityObject
entity.Id = row.Id
// Etc.
Return entity
End Function
He’s not with the company anymore, so I can’t ask him why he’s done it this way. Hence my question here. Is there some performance gain, or traceablity thing with nHibernate by using the first implementation rather than the latter?
When at the university I was always told not to pass the return object to the method, unless there was a very specific reason for it.
Please advice. 🙂
From the information you gave there is no problem to create the object to return from inside the method and not receive it from outside.
The only reason I can see for this is that maybe he passes the entity as a parameter with its ID already defined and doesn’t change it inside, because the dataset could not know the entity’s ID. But I guess that’s not the case. So in my opinion go ahead and do the way you propose.