I would consider it an architecture smell in that UpdateData probably should belong to a 'service' class.
Where the data is an Apple.
Where AppleAdapter is service/business-intelligence class.
Where AppleService is a Singleton reference to an AppleAdapter that exists outside of the current method.
private static volatile AppleAdapter _appleService = null;
private static object _appleServiceLock = new object();
private AppleAdapter AppleService
{
get
{
if (_appleService == null)
{
lock (_appleServiceLock)
{
if (_appleService == null)
_appleService = new AppleAdapter();
}
}
return _appleService;
}
}
public SomeAppleRelatedMethod(Apple apple)
{
AppleService.UpdateData(apple);
}
I don't think what you are doing is wrong necessarily but if SomeDataAdapter does indeed represent some kind of stateless business service, then a singleton would be the best practice for it.
Hope that helps! The example provided is fancy way to ensure no contention of the _appleService if it happened to be both null and accessed at exactly the same time by two or more threads.
You know what? If SomeDataAdapter is an ADO IDbDataAdapter (which it almost certainly is), disregard this entire response!
:P
I don't have permission to add a comment to the original question, but if you could specify where this code exists.
If this code represents a custom implementation of an IDbDataAdapter, and UpdateData is creating an IDbConnection, IDbCommand, and wiring it all up behind the scenes, then no I wouldn't consider that a code smell because now we're talking about streams and other things that need to be disposed of when we're done using them.