Surely the user sessions must be kept somewhere serverside as well...
If you display a message together with the username, then the MessageDTO should contain the username as well.
In my eyes nr 1 and 2 are the same. In the application layer you have "public MessageDTO GetMessage()". The MessageDTO contains the username. The method is not specific for any particular view - you could consume this method from many different presentation layers that wants to show a message. Just skip the "ForView"-part when naming the method 8-)
Thank you for your reply.
This forum post told me that it was bad: #1028@04dacffb-ff73-44de-bd9a-d17e1b6edf03
I actually ignored that advice at first and let my appservices use each other as needed, but when I had a controller use 2 appservices which in turn used eachother I got a circular reference error.
Spreading the common code into baseclass, managers and helpers works, but it also works with using just helpers like I already do.
The thing is I would like to know the best practise way. So all of you gurus out there feel free to join in ;)
Anyone?
An example of such code could be:
// ci is the DTO and this code is used by several appservices. Where to put it so I can follow "DRY" and without letting one appservice reference another appservice?
ci.Price = await _exchangeRatesManager.GetPriceInCurrentCurrency(ci.Price, geo.Currency);
// _exchangeRatesManager is a domain service
ci.Tax = await _taxManager.GetTax(geo.Region, ci.Price, ci.TaxClass);
// _taxManager is a domain service
ci.xx = await ...
...
I solved it finally. For anyone else looking for an answer, here is the solution: Somehow I had missed this in the documentation:
If you are in a static context or can not inject IIocManager, as a last chance, you can use singleton object IocManager.Instance everywhere.
So now I can do this:
ITenantAppservice tenantAppservice = IocManager.Instance.Resolve<TenantAppservice>();
string theme = tenantAppservice.GetCurrentTenantTheme();
Sweet!