Service Layer vs. Helper Objects?

Question

Hello, I'd like to have your opinion on a specific case, please. This is about Service Layer vs. Helper Objects - and I'm not looking for idealistic patterns, but merely a good understanding of what my dear programming colleagues think about this:

In my current application I have a full domain model (Linq to Sql, extremely lightweight repositories and then use extension methods across IQueryable<> to filter/sort/order based on business requirements), and then a service layer which contains services based on grouping of responsibilities, such as IRegistrationService (register users, check availability of login names etc.)

Now the caveat. I also have some "Helper" classes which do things like encryption, and I've also stuffed other otherwise ungroupable elements in that directory (such as custom enums etc.)

I need to create a new class now which will handle the generation of custom links for my application, which is barely more than String.Format with different objects and taking their properties into account. The inner workings are irrelevant. However, I have a hard time instantiating some kind of "LinkService" now that'll do that - I feel like I'm going to end up with 100 services (and their interfaces + implementation) when I'm done.

At the same time I don't feel like I want to create some loose mix of classes and other stuff in my "Helpers" namespace/directory (e.g. LinkManager).

What to do? Where do you guys put stuff that's still somewhat business layer level, but at the same time how do you limit the number of items in your business/service layer? Where do you stick all those little helper classes, such as intermediate objects that simplify and manage Session access (I assume you want to have this strongly typed - at least I do)?

Let me know what you think? Thanks !

Answer 1

To me, using the right tool for the job is key. If you need some kind of facility to generate links, which is basically a mapping of entity properties to formatted strings, then write a facility to do that. It doesn't have to be a service...on the contrary, having a full blown service for something like that is probably overkill. However, I wouldn't just lump this into your general "helpers". It sounds like this is something that has a specific purpose and intent, with a specific kind of behavior behind it. As such, put it in a location appropriately suited for that behavior...even if thats a new project.

I try not to have a huge lump of "general" code in my applications. Everything has a purpose and implements a specific behavior. Sometimes that purpose and behavior are highly reusable, but I still try to organize those reusable elements of my domain logically. From a high level, I see most of my applications divided into the following:

1. Client
2. API/Service
3. Domain
4. Data Access (Optional)
5. Framework

A lot of this kind of reusable functionality falls in sort of a nether region between Framework and Domain. Part of it may exist as some base classes and/or interfaces and supporting types in Framework, with the other half, the concrete implementations, residing within my Domain. It sometimes seems odd, but organizing it this way helps me keep my domain as clean as possible (dedicated to business concerns), while still allowing me to abstract common and reusable concepts into lower level "framework" types.