0

I'm trying to apply hexagonal architecture to a project which will have several apps having to deal with the same domain model.

We will have for example an mvc website requesting the application service which will then deal with the domain model and data access layer. Everything is fine so far.

The question I have is when should I instantiate an application service class. Should I have only one instance of any class for all users (singleton) ? Or should I instantiate one per user and then have it hold some user data and be stored in user session ? Or should I instantiate a new class for each request ?

Of course any of these options is possible but I would like to get your best practices advices.

I guess the more stateless the class is the better it is, but stateless classes mean I need to pass user specific data with each method call which I don't particularly like.

Jonathan
  • 1,086
  • 7
  • 31

1 Answers1

1

I generally keep my services and persistence classes in request scope. This is helpful to ensure that I can revert a data transaction if something goes wrong and I'm not left with partial data.

As for why you don't want a longer lasting transaction scope, it's usually a very poor way of improving performance and can lead to a unexpected behavior. Particularly when it comes to singletons that depend on transients or scoped classes. Because since the singleton is created once, its dependencies are created once. This is super dangerous with classes that aren't thread safe. More on scopes here.

As for your concerns about passing user data in. I would put all of the info you care about behind some sort of user data helper interface. Make your service rely on that rather than passing that data in. Then you can make a user data helper that is specific to the client you want to support. You can use dependency injection to configure your mvc app to use the mvc specific implementation of that user data helper. And other clients in your architecture can do the same thing.

I would code a custom interface for the user info helper for exactly what your existing service needs. The custom implementation can be based off of session data or whatever your client can provide. That is, the implementation might rely on existing libraries but transforms this data into a common format for your service layer to use. That way you can swap out where your user info comes fropm in the helper without breaking the rest of your application.

Tracy Moody
  • 989
  • 4
  • 16
  • Thanks for your answer, it is interesting. Can you please provide me with an example or reference about the "user data service" you talk about ? Could it be some sort of session object ? (not the HttpSessionState object but a custom interface) – Jonathan Sep 21 '17 at 12:57
  • @Jonathan I tried adding clarification to my answer (and switched to calling the user data class a helper instead). – Tracy Moody Sep 21 '17 at 13:40
  • So what you say is to generally instantiate a service class with each request and pass the user data helper in the constructor through a common interface. That helper will be used to retrieve user data from the client app right ? At first I wondered why not passing directly the user data thru that interface, but its true that the user data may come from many sources, therefore it is probably better to retrieve it on demand than gathering all data before calling the app service class, am I right ? I better understand why you named it a user data service at first. – Jonathan Sep 22 '17 at 12:17
  • @Jonathan That's correct. You'll have a helper for every different way you gather that information. But your service operates on an interface and can be reused. – Tracy Moody Sep 22 '17 at 12:43