Is there such thing as standard naming convention for a class that interact with database ( CRUD things or check duplication ). Right now i just named it as Helper, for example a named “Subscriptions” A class that
interact with that table will be named “SubscriptionHelper”
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace LoopinWineBackOffice.Helper
{
public class SubscriberHelper
{
public static bool IsEmailAlreadyInUsed(string email)
{
using (var dc = new LoopinWiineContainer())
{
return dc.Subscribers.Any(item => item.Email==email.Trim());
}
}
}
}
My sample code is something like this.
In my experience [and no offense intended] when classes start getting names like ‘Helper’ and ‘Manager’ it’s because the purpose of that class hasn’t been well defined (and I have been guilty of this in the past myself).
In this case, I would speculate that you haven’t really thought about your data access pattern, and you’ve just got a bunch of ad-hoc SQL in the ‘SubscriptionHelper’ class.
Now, if you were implementing a standard data access pattern, for example a Repository pattern, your class would be called SubscriptionRepository, and its intent would be alot clearer.
So, in answer to the question – No, I don’t think there is a standard ‘naming’ convention for your scenario. What there are though, are several standard design patterns which you could potentially apply to your system, and through doing so, you would likely end up with a naming convention which is both informative, and meaningful.
Here’s a starting point for some well known design patterns for you: http://martinfowler.com/eaaCatalog/, but without knowing more about the project, it would be hard to direct you much further than that.