I would like to receive your opinion on a specific case, please. It's about Service Layer vs Helper Objects, and I'm not looking for idealistic templates, but just a good understanding of what my dear programming colleagues think about it:
In my current application, I have a complete domain model (Linq to Sql, extremely lightweight repositories, and then use the extension methods in IQueryable <> to filter / sort / organize based on business requirements), and then a service level that contains services on based on grouping responsibilities such as IRegistrationService (register users, check for login names, etc.).
Now a warning. I also have some Helper classes that do things like encryption, and I also stuffed other unprivileged elements in this directory (like user enumerations, etc.).
I need to create a new class that will handle the generation of custom links for my application, which is hardly more than String.Format with different objects and takes into account their properties. Internal work does not matter. However, it’s difficult for me to create an instance of some kind of “LinkService” that will do this - I feel that when I finish, I will have 100 services (and their interfaces + implementation).
At the same time, I don’t feel that I want to create a free mix of classes and other things in my Helpers namespace / helper (for example, LinkManager).
What to do? Where do you guys add material that is still at the business level, but at the same time you limit the number of items at your business / service level? Where do you stick with all these small helper classes, such as intermediate objects, that simplify and control session access (I assume you want this to be strongly typed - at least I)?
Let me know what you think? Thanks!
source
share