title: Service Layer vs. Helper Objects?
body: <p>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:</p>
  
  <p>In my current application I have a full domain model (Linq to Sql, extremely lightweight repositories and then use extension methods across IQueryable&lt;> 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.)</p>
  
  <p>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.)</p>
  
  <p>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.</p>
  
  <p>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).</p>
  
  <p>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)?</p>
  
  <p>Let me know what you think? Thanks !</p>