What to name a static "service" and where to place it in mvc solution

Question

I have a site structure as below:

• ProjectName.Core - entity framework, context, migrations, interfaces, extensions, enums
• ProjectName.Models - DTOS's only
• ProjectName.Repositories - Repositories only
• ProjectName.Services - services instanciated via ninject talking to repositories, automapper config
• ProjectName.Tests - speaks for itself
• ProjectName.Web.Customer - customer mvc site
• ProjectName.Web.Admin - Admin mvc site

My question:

Where would i put static "helper" classes such as below, and what should i call them?

• razor parser
• serializer/deserializer
• Email sender

It feels wrong calling them services and placing them together with the non static services, it's not intuitive to another developer...

Answer 1

I would like to address some ambiguities that I have noticed in the structure you have given in your question. By looking at your structure I'm assuming that you are trying to implement some sort of a Onion-/Clean-/Hexagonal architecture.

If you analyze the proposed architectural guidelines above it will become clear on the first sight that your Core project should not contain anything that is an infrastructural concern such as Entity Framework in your case. The core itself should only contain your business/domain models (along the business rules) and domain services.

Now lets just think for a second: how would the tests of Core look like if you are going to get EF or any other infrastructural concern into the picture? By testing Core you are usually trying to test one thing at once... so you don't have to mock out the rest of the dependencies.

Now to answer your question exactly, naming things is not easy. I see that an answer recommends you to separate things from the rest of your application. Which in itself is good, but I wouldn't recommend it, it can become a pain if you use a lot of projects just for the sake of some good practices. An example reason I'm writing this is just think about the extra time to compile your solution with 3 extra projects for 3 different things?

My suggestion to organize these infrastructural concerns are as follows:

1. Create a project called ProjectName.Infrastructure

   • Add the each of the required NuGet packages/DLL references to the project
   • Create directories inside this project to organize your services

2. Add/create the implementations of your services here per directories you have create

   • Make sure each service implements an interface that you will get injected in your consumer classes
   • As a good advice separate these services by namespaces according to class names, eg.: ProjectName.Infrastructure.EmailService

3. The last part is to wire these infrastrucal concerns together via NInject

Final words: I hope you really don't need these services to be static at class level as you wrote. If so, you could still bind them that way via the proper NInject binding scope.