Im trying to improve my code structure so perhaps i could get some input on the following points and questions regarding how to handle primarily services.
-
A service should not be dependent on the presentation layer, so passing stuff like httpcontext into service / service functions through constructor and similar is a bad practice, correct?
-
Should one not have services referencing each other? Should they only work ‘downward’ like for example repository dependency? Or that is considered ok?
-
Would a service only contain functionality directly related to filtering and processing information from the database / repository or could one consider for example a class dedicated purely to encryption and generating random strings / passwords or a class handling provider relying party functionality a service as well? Or they / one would be considered utility classes perhaps?
-
Is there a good and accepted way to manipulate sessions inside a service or this should be passed to the controller and handled there?
If you can avoid it, avoid it. But it depends, if its a service for the presentation layer, then it can be OK.
If you can avoid it, avoid it. It dependes on you architecture, if, for example, your are working in asp.net mvc, you would do well in avoiding this, and keeping the kind of code that orchestrates your multiple service at the Controller level
You can use services for filtering and processing information from the database / repository or you can also create one dedicated purely to encryption and generating random strings / passwords. Services are classes, so it is important that they follow the Single Responsability Principle
It is better for scaling if your services are stateless, but if you are going to have to deal with sessions or other lifecycle stuff, and you are building web systems in .net, the best you could do is to use asp.net mvc, integrated with Unity so that you get Inversion Of Control, that way you can deal with session using life time managers