I have a service where users can upload/download/replace/delete files. These files have about a dozen attributes that are saved to a SQL Database. Periodicaly throughout their session they will have to download a summary (FileName, size0in-KB, and ID) of a subset of files.
When working in the service it creates an object of these attributes (FooObject) in the DB. But, when the info is sent to the User, a summary object (FooObjectSummary) is created. FooObjectSummary has 3 attributes, FooObject has 12 or so (none of the attributes are anything but strings or primitive types).
I originaliy did this so that as little extra info would be transferred across. None of this extra data in FooObject would be dangerous for the user to have, but it wouldn’t be exposed to them anyways?
Am I just writing extra code? Or is it good practice to only expose the user to as much info as they need and not a bit more?
As with all things, it depends.
The Interface Segregation Principle indicates you should probably have the two views into the data so that you’re not breaking consumers if one of the non-vital properties is changed.
In general, you shouldn’t share the interface that you use to get at the database with consumers. What happens when you want to change how the data is stored, but keep the consumer interface the same? Though not obvious the gist of the Single Responsibility Principle applies here too.
All that said, if that interface really is going to be the same (if you change either the consumer interface or the SQL interface both are going to need to change regardless [your service is just a pass-thru]) and the extra data really isn’t big or important then saving the time and complexity might be best.
You’ll need to weigh the time saved versus the likelihood that violating the two principles will bite you in the ass later on.
I can see why you’ve gone down the path you have and understand your reasons for doing it. After all why go and get twelve properties when you’re only going to use three. Why send an object with twelve properties when you are only going to display three. It just feels tidier to do it the way you have.
I’m not going to say you are right or wrong. All I’d say is that if more and more properties start being added to FooObjectSummary then it starts to look like needless duplication. Right now I’d say it’s something to be aware of, but I’m sure you’ve got other more pressing issues.
It’ll be interesting to know what others think though.
Don’t Confuse Server Interfaces With Inner Interfaces
The client interacts with the server and exchanges data based upon the published interface for that server. What the server does to create that data doesn’t matter to the client, and the server should not send unwanted or useless data that only pertains to the server.
While the server maintains an inner object called FooObject and sends a FooObjectSummary. The two really are not the same thing. One is an inner data model that relates to database storage, and the other is a communications response to be sent to the client.
If you alter your class names, then things start to become more clear. FooObject is renamed to FooModel and FooObjectSummary is renamed to FooResponse. Now you centralize your code so that only FooModel is used to create a FooResponse.
class FooModel
{
public FooResponse getResponse() {....}
}
You can now document that the server will only send response objects for requesting data.