views:

71

answers:

1

I am in the process of updating a website for the third time in in 2 years, looks like this is going to happen all of the time and several websites are using the same DB. I want to use the same code for all of them and keep it easy to update in the future. So I plan on writing some interfaces and then place the business login in a service to keep things consistent across the board and add in some unit testing.

So I am looking at my current repositories and I am not sure what should be in my Interface and what should be in my Service.

For example I have an Add method - no brainer I have an Add in the interface and an add in the Service.

Then I have an AuthenticateAccountManager method that takes 3 parameters, should this be in both or just the Service and have a simple Get method in my interface (say by Username) and then do the validation against th other 2 properties in the Service.

I also have a QualifyPartner that sets a bool to true, should this just be in the Service and again have a simple Get method in my Interface, trying to keep that as small as possible?

+1  A: 

Following the Separation of Concerns principle- AuthenticateAccountManager is a service-level operation. It should call into your repository, which will return the raw User data. The service then authenticates or not based on what is returned by the repository.

The general guideline is that the repository is responsible for retrieval and committing of data only. Interpreting and executing behaviors based on the data is business logic.

Dave Swersky
thanks - just needed a little reassurance :)
Slee
so I have about 20 related tables, and now I need my service to interact with one of those related tables, do I add methods to my current Interface or create a new one for this new table? If that's the case my service will end up with crazy interface madness - how do I decide what right to do?
Slee
This is where OR/M tools help a lot. Let Entity Framework or Mindscape Lightspeed generate your repository for you.
Dave Swersky
PS- If you go with Entity Framework there is a good generics-based repository for EF here: http://www.codeproject.com/KB/database/ImplRepositoryPatternEF.aspx
Dave Swersky
then you are tied back up to an ORM and tightly coupled again aren't you?
Slee
You have to put up with *some* coupling if you don't want to spend hours writing boilerplate.
Dave Swersky