A design question
-
Hi all, I was hoping for some advice on 'best practices' regarding the design of an app I'm working on. It's a subscription-based web app in C#. Member data is stored in a DB table cunningly named Members. I've implemented a fairly simple Member class which essentially wraps access to a row in the table, with functions like: static public Member FetchFromDB( int iMemberID ); public void UpdateInDB(); etc. and getters/setters to map the contents of the Members row, like: public DateTime ExpiryDate{ get{ return _expiryDate; } } public StatusEnum Status{ get{ return _status; } } etc. I'm happy with this class as described so far. It does one job, maintains a constant level of abstraction/encapsulation, etc. However, My app also needs functionality like 'Check whether a member's ExpiryDate is in the past, and if so update their Status to Expired', or 'Update LastOnline to now'. The way I've been doing this so far is to add methods to Member such as UpdateLastOnlineToNow(), CheckExpiryDate(), etc. Obviously this works fine, but I'm finding myself adding more and more 'utility' methods to Member, and I'm starting to think that Member has a 'bad smell' - it's still a wrapper for the DB, but it's also getting more and more higher-level functionality mixed into it. This class is just an example, I'm also getting similar bad smells with various similar classes in my app (Message, for example, which encapsulates my message sending/receiving system). So my question is, what do all you wise and esteemed CPians think? Have I been reading my Patterns books a bit too religiously? If I not, what would be the best way to refactor this? One thought I had is to break Member out into 3 classes, a low-level wrapper to the DB, a high-level wrapper that uses the low-level wrapper internally, and a utility class that also uses the low-level wrapper. Is this overkill? Any other suggestions (or any thoughts at all) gratefully appreciated! Cheers, Pete