What is recommended architectural approach for defining dependencies in a service class ?
Is this OK, when another class, ex. OrderService has dependencies to repository class ex. CartRepository instead of CartService? Should I always create one repository and one service per domain object ?
public class CartService : ICartService
{
private IBuyerRepository _buyerRepository;
private ICartRepository _cartRepository;
private IConfigService _configService;
private ISimpleDataService _simpleDataService;
public CartService(IBuyerRepository buyerRepository,
ICartRepository cartRepository,
IConfigService configService)
{
_buyerRepository = buyerRepository;
_cartRepository = cartRepository;
_configService = configService;
}
public void Save(Cart cart)
{
_cartRepository.Save(cart);
}
}
OrderService file:
public class OrderService : IOrderService
{
public OrderService(ICartRepository cartRepository)
{
}
}
Your implementation is good as a first step, and in a simple, not too big, domain.
A such implementation has avantages:
While just one service per http resquest manages all the repositories it needs, there is no difficulty to manage the sql transaction to maintain integrity.
It has too disadvantages:
You could write two times, or more, the same business rules... We all are lazy so it's a problem. But a major failure will come when someone, or you, 6 months later, will call the repository for the third time in its service implementation and forget a business rule... bye bye lovely domain...
My recommendation would be that a service just call its repository, and calls the other services that encapsulate their own logic, when needed.
The only trick to remember is to propagate the transaction to avoid odd things to happen.
Hope it helps,
Julien
Related
So recently I started a project with Ardalis Clean Architecture as template it was all nice but when signalR came into my project i can't figure it. I'm trying to inject interface that my hub implements and call it's method, but everytime when it's called it throws NullReferenceException, it seems like all of the signalR components are null within this injected interface. Registered all hubs and registered it's interfaces using AutoFac. Trying to avoid situation when I'm forced to reference signalR package within core layer.
Core layer:
public class UpdateTimerNotificationHandler : INotificationHandler<UpdateTimerNotification>
{
private readonly ITimerHub _timerHub;
public UpdateTimerNotificationHandler(ITimerHub timerHub)
{
_timerHub = timerHub;
}
public Task Handle(UpdateTimerNotification notification, CancellationToken cancellationToken)
{
return _timerHub.UpdateTimerAsync(notification);
}
}
public interface ITimerHub
{
Task UpdateTimerAsync(UpdateTimerNotification updateTimerNotification);
}
Infrastructure layer:
public class TimerHub : Microsoft.AspNetCore.SignalR.Hub, ITimerHub
{
private readonly IAccountRepository _accountRepository;
public TimerHub(IAccountRepository accountRepository)
{
_accountRepository = accountRepository;
}
public Task UpdateTimerAsync(UpdateTimerNotification updateTimerNotification)
{
return Clients.All.SendAsync("UpdateTimer", updateTimerNotification);
}
}
private void RegisterHubs(ContainerBuilder builder)
{
foreach (var assembly in _assemblies)
{
builder.RegisterHubs(assembly);
}
builder.RegisterType<TimerHub>().As<ITimerHub>();
}
Web layer:
builder.Host.ConfigureContainer<ContainerBuilder>(containerBuilder =>
{
containerBuilder.RegisterModule(new DefaultCoreModule());
containerBuilder.RegisterModule(
new DefaultInfrastructureModule(builder.Environment.EnvironmentName == "Development"));
});
builder.Logging.ClearProviders();
builder.Logging.AddConsole();
var app = builder.Build();
GlobalHost.DependencyResolver = new AutofacDependencyResolver(app.Services.GetAutofacRoot());
I was trying manually registering hubs with no luck, still same issue
The good news is SignalR already implements IHubContext<T> In your case you don't need to inject ITimerHub interface. If your TimerHub Already Implements ITimerHub that's good enough In your case it would look like this
public class HomeController : Controller
{
private readonly IHubContext<TimerHub> _hubContext;
public HomeController(IHubContext<TimerHub> hubContext)
{
_hubContext = hubContext;
}
}
Also you didn't show your startup.cs class.
public void ConfigureServices(IServiceCollection services)
{
...
services.AddSignalR();
...
}
and
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
...
app.MapHub<TimerHub>("/yourEndPointGoesHere");
}
If you really wanted to, which I don't recommend is [look at it here][1]
There is an example on using IHubContext in generic code.
I understand you're trying to learn something new. And yes, it's important to decouple application so you're headed in the right direction in what you want to achieve. However I wouldn't recommend this approach you are taking. His approach doesn't apply to 99% of the projects out there. Let me explain my point of view. Don't get pulled in by the buzz words in his videos and blogs. It's important to understand that these principals are SUBJECTIVE to your application.
You don't have 15,000 classes, services, views, and N Layers etc... in your app.
You don't need the flexibility of a domain driven approach. I've seen massive and I mean massive projects, ones that are 25 years old and have millions of lines of code. Let me tell you you're not swapping out your data layer all willy nilly like he makes it seem to be. On a big project there is no "it makes it easy" way to do that. Putting it in Repos and a data access layer doesn't really help. You can put in a data access layer, or in your services. You still need to test out 150,000 lines of code. The only time it's been useful for me is when I've had 4 data sources all having a getBy... function that needs to aggregate info from 4 sources. You don't need it for unit testing either. Just create a mock variable in your unit tests no need to mock your db connection. I find it more useful to have your unit tests actually hooked up to a database even though it's a dependency, it's actually useful.
He said it himself "You can go with a minimalist API and work your way up from there" Which is what you should do. What's the point of SOLID and Repos in a project with no code? For example the I in solid is implementation of interfaces. Interfaces do 2 things -
A. Tell your application what it should and shouldn't do. so, what are you enforcing that could break or needs this kind of abstraction?
B. Decouple the application. Where do you have 3+ different classes being injected in one piece of code with the same DoSomething() based on the type?
He touches over other things that only apply when you have 500 different things going on, and his case it's still overkill.
If you want to break it up you can take a simple approach.
-MainApiProject
-ServicesProject (you can also put interfaces in here)
-InterfacesProject(if you need them between multiple projects and have a lot of them)
-UtilitiesProject
Then look at what he's doing and if you see you need it take it.
I can go on but this is getting long as is.
[1]: https://learn.microsoft.com/en-us/aspnet/core/signalr/hubcontext?view=aspnetcore-6.0
I have several services that are currently highly decoupled. Now I have to extend them and they need to depend to access each other.
Let's say I have 4 services: EmailService, HouseService, UserService, PriceService. Each user has an email address and each user belongs to a house.
I want to send an email to each user about the price of the house that they are connected to. So in the EmailService I have SendEmailToAddress(string email, string text), in PriceService I have GetHousePrice(int id), in HouseService I have GetUsersInHouse(int id) and in UserService I have GetEmailOfUser(int id).
What would be the best approach to send an email to all the users from the HouseController? Should I just init all the services in the controller action and call each one in order or should I use the Mediator pattern? If I should use it, it would probably contain only one method so it seems a bit of an overkill. Also if I use it everywhere should I create different mediators for each service connection or should it be only one class that has all my services as private properties and then in the methods use only the once I need for a specific action? If I go with the Mediator pattern should I use it in every controller or should I stick with the bare services where they don't need to interact together (e.g. if I only need a list of houses I think it's probably best to just get them directly from the service object instead of the Mediator)?
Given that your services aren't actually needing to communicate with each other, you just need to call various methods on each and use the return values to complete a higher level task, I don't think the Mediator pattern is appropriate here.
For example, its not like you need the HouseService to manipulate the state of objects managed by the PriceService...you just need data from the PriceService that the HouseService provides input for:
var houseId = houseService.GetIdOfHouse(someCriteria);
var price = priceService.GetPriceOfHouse(houseId);
Instead, I think what you need to implement is the Facade pattern, which will:
Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use.
Good example of Facade pattern can be found on the dofactory.com site:
http://www.dofactory.com/net/facade-design-pattern
Here's what I would consider doing:
public class NotificationFacade
{
private IPriceService _priceService;
private IHouseService _houseService;
private IUserService _userService;
private IEmailService _emailService;
public NotificationFacade(IPriceService priceService, IHouseService houseService, IUserService userService, IEmailService emailService)
{
_priceService = priceService;
_houseService = houseService;
_userService = userService;
_emailSerice = emailSerice;
}
public void NotifyUsersAboutPriceForHouse(int houseId)
{
var price = _priceService.GetHousePrice(houseId);
var users = _houseService.GetUsersInHouse(houseId);
foreach(var user in users)
{
var emailAddress = _userService.GetEmailOfUser(user);
_emailService.SendEmailToAddress(emailAddress, "Your House Price is:" + price);
}
}
}
In your controller:
public HouseController
{
private NotificationFacade _notificationFacade;
public HouseController(NotificationFacade notificationFacade)
{
_notificationFacade = notificationFacade;
}
public void SomeActionMethod(int houseId)
{
_notificationFacade.NotifyUsersAboutPriceForHouse(houseId);
}
}
The dependencies should be resolved using Dependency Injection with a container such as Unity, Ninject, StructureMap or something similar...
You could create a workflow service that contains the actual logic to look up the information and send the mail using the existing services.
This service is then called from your HouseController. You could use the service directly as a class library or expose it as a WCF service; but it depends on your requirements.
This way your entity services remain loosely coupled, and all of your cross-service logic is in a dedicated component.
As I was looking for best practices since past couple of days in ASP.Net MVC and I concluded that our services should contain all business logic ( using repositories of different domain models) and expose public methods that are accessible by controller.
In your case you should create a new service and put the whole logic of calculation and sending email in a method of that service. So that your service will work like a black box. Other developers (who work on your project) don't need to know that how thing are managed in that method. All they need to know is to call that method with required parameter and handle response.
Just create HouseServiceFacade that contains the services you need. In this facade you can put all methods for the controller.
We are implementing ntier architecture for one of the project which uses EF6 ORM. DbContext scope is managed by ContextStoreFactory. Based on configuration ContextStoreFactory uses HttpContextStore/StaticContextStore to create DbContext. For console app its working fine. Now we planning for implemnting a wcf service with net.msmq binding which uses underneath services to process incoming request.
public class TestService : ITestService
{
public void ProcessPerson(Person person)
{
var repo = GetRepository();
var personService = new PersonService(repo);
personService.Process(person);
}
private IRepository GetRepository()
{
var context = ContextStoreFactory.GetContextStore().GetContext();//Calls OperationcontextStore
return new Repository(context);
}
}
I would like to manage the DbContext scope in wcf service. I come across many articles which says its best to use DBContext per call/operation. My sample OperationContextStore looks like follows. Please feel free to correct if it requires any correction.
public class OperationContextStore
{
public static readonly string ITEM_NAME = "DBCONTEXT-INSTANCES";
public DBContext GetContext()
{
if(!OperationContext.Current.OutgoingMessageProperties.ContainsKey(ITEM_NAME))
OperationContext.Current.OutgoingMessageProperties.Add(ITEM_NAME, new DBContext());
return (DBContext)OperationContext.Current.OutgoingMessageProperties[ITEM_NAME];
}
public void Dispose()
{}
}
I would like to know Is DbContext scope per call is valid in my scenario?
Is the approach to create Repository in my service method is valid?
Are there any best practices to wire this up without using IOC?
I know it's late to answer my own question and I will try to recollect what I did
I would like to know Is DbContext scope per call is valid in my scenario?
Yes,It was valid in my scenario.
Is the approach to create Repository in my service method is valid?
I ended up having IRepository as a property in my service class and did a property injection.
Are there any best practices to wire this up without using IOC?
I ended up writing my own utility. Please search for poor man's dependency injection.
I have implemented repository pattern and it works pretty well.
public interface IServiceRepository
{
User GetUser(int id);
User GetUser(string email);
User GetUser(string email, byte[] password);
//SkipCode
}
//Service repository where I keep extended methods for database manipulation
public class ServiceRepository : IServiceRepository
{
private readonly IRepository<User> _userRepository;
private readonly IRepository<Order> _orderRepository;
private readonly IUnitOfWork _unitOfWork;
public ServiceRepository(IRepository<User> userRepository, IRepository<Order> orderRepository, IUnitOfWork unitOfWork)
{
}
//SkipImplementation
}
When I want to access some methods from IServiceRepository in Controller I do this
public class AccountController : Controller
{
private readonly IRepository<OrderDetail> _orderDetailRepository;
private readonly IRepository<UserDetail> _userDetailRepository;
private readonly IServiceRepository _serviceRepository;
public AccountController(IRepository<OrderDetail> orderDetailRepository, IRepository<UserDetail> userDetailRepository, IServiceRepository serviceRepository)
{
_orderDetailRepository = orderDetailRepository;
_userDetailRepository = userDetailRepository;
_serviceRepository = serviceRepository;
}
}
As you see I inject IRepositories and IServiceRepository in this scenario. Sometimes I inject only IRepositories or IServiceRepository depending on a needs.
Question would be maybe I should move all IRepositories into IServiceRepository. And in all controllers embed only IServiceRepository and access IRepositories from IServiceRepository? This implementation looks more clear to me because only IServiceRepository will be injected in controllers. But to access for example one Repositorie<User> from ServiceRepository will need to build and inject all other repositories in ServiceRepository, so it may slow down the whole application. What do you think?
My answer is controversial, so please bear with me :)
To the point
Building and injecting repositories should take almost no time. I assume your repositories do not open any connections when they are created, so do not bother about micro optimisation, just get it working :)
You can merge your interfaces, as long as the result interface is small (say no more than 10 or so methods), focused and has a clear purpose.
Side comments
What is the need for the repository pattern? Do you allow (or in the nearest future plan) to easily switch between databases? For most cases repository is a massive overkill and a maintenance problem.
Consider this code
public interface IServiceRepository
{
User GetUser(int id);
User GetUser(string email);
User GetUser(string email, byte[] password);
//SkipCode
}
What does it tell me? Well, from the generic name I couldn't understand what this interface does, it is like service of a service, abstraction over abstraction. But from the method definitions I see it does something with Users.
Why do you explicitly using IUnitOfWork? Is it not already implemented by the data provider you using?
Instead of all this architecture (of course if possible), just use ORM directly, this is easy to do and maintain, reliable and fast.
Your ServiceRepository seems to be closer to a domain service in a Service Layer than a repository of its own.
A domain service typically coordinates a sequence of interactions with various data repositories, for example loading a customer from a customer repository and a list of orders from an order repository to present a unified view of a customer and all their orders. As such domain services are used to create an operational boundary around an application - abstracting the various sequences of data access.
This is a fine approach, but I think the problem you have is that you have not taken it far enough. If you decide that the operations of the application should be encapsulated into a series of domain services, then there will be no need for a Controller to access repositories. If on the other hand you decide that the Controllers will take that reposibility, and access repositories themselves, then your ServiceRepository class, and others like it, basically become utility classes.
I see that you have two options - improve your service layer to such an extent that controllers no longer need repositories:
public class AccountController
{
public AccountController(IAccountsService service)
{
_service = service;
}
public void SomeActionMethod(Foo someParams)
{
_service.SomeAction(someParams);
}
}
or call the ServiceRepository what it is, a shortcut utility for doing a fixed sequence of data accesses...
public class AccountController
{
public AccountController(ICustomerRepository customerRepo, IOrderRepository orderRep)
{
_customerRepo = customerRepo;
_orderRepo = orderRepo;
}
public void SomeActionMethod(Foo someParams)
{
var utility = new CustomerOrderBuilderUtility(_customerRepo, _orderRepo);
var customerWithOrders = utility.GetCustomerAndOrders(someParams.CustomerId);
// some domain logic...
}
}
I was asked to implement castle dynamic proxy in my asp.net web application and i was going through couple of articles which i got from Castle Project and Code Project about castle dynamic proxy in asp.net web application....
Both articles delt with creating interceptors but i can't get the idea why interceptors are used with classes.... Why should i intercept my class which is behaving properly?
Let's say that your class needs to do 3 things for a certain operation:
Perform a security check;
Log the method call;
Cache the result.
Let's further assume that your class doesn't know anything about the specific way you've configured your security, logging, or caching. You need to depend on abstractions of these things.
There are a few ways to go about it. One way would be to set up a bunch of interfaces and use constructor injection:
public class OrderService : IOrderService
{
private readonly IAuthorizationService auth;
private readonly ILogger logger;
private readonly ICache cache;
public OrderService(IAuthorizationService auth, ILogger logger,
ICache cache)
{
if (auth == null)
throw new ArgumentNullException("auth");
if (logger == null)
throw new ArgumentNullException("logger");
if (cache == null)
throw new ArgumentNullException("cache");
this.auth = auth;
this.logger = logger;
this.cache = cache;
}
public Order GetOrder(int orderID)
{
auth.AssertPermission("GetOrder");
logger.LogInfo("GetOrder:{0}", orderID);
string cacheKey = string.Format("GetOrder-{0}", orderID);
if (cache.Contains(cacheKey))
return (Order)cache[cacheKey];
Order order = LookupOrderInDatabase(orderID);
cache[cacheKey] = order;
return order;
}
}
This isn't horrible code, but think of the problems we're introducing:
The OrderService class can't function without all three dependencies. If we want to make it so it can, we need to start peppering the code with null checks everywhere.
We're writing a ton of extra code to perform a relatively simple operation (looking up an order).
All this boilerplate code has to be repeated in every method, making for a very large, ugly, bug-prone implementation.
Here's a class which is much easier to maintain:
public class OrderService : IOrderService
{
[Authorize]
[Log]
[Cache("GetOrder-{0}")]
public virtual Order GetOrder(int orderID)
{
return LookupOrderInDatabase(orderID);
}
}
In Aspect Oriented Programming, these attributes are called Join Points, the complete set of which is called a Point Cut.
Instead of actually writing dependency code, over and over again, we leave "hints" that some additional operations are supposed to be performed for this method.
Of course, these attributes have to get turned into code sometime, but you can defer that all the way up to your main application code, by creating a proxy for the OrderService (note that the GetOrder method has been made virtual because it needs to be overridden for the service), and intercepting the GetOrder method.
Writing the interceptor might be as simple as this:
public class LoggingInterceptor : IInterceptor
{
public void Intercept(IInvocation invocation)
{
if (Attribute.IsDefined(invocation.Method, typeof(LogAttribute))
{
Console.Writeline("Method called: "+ invocation.Method.Name);
}
invocation.Proceed();
}
}
And creating the proxy would be:
var generator = new ProxyGenerator();
var orderService = (IOrderService)generator.CreateClassProxy(typeof(OrderService),
new LoggingInterceptor());
This is not only a lot less repetitive code, but it completely removes the actual dependency, because look what we've done - we don't even have an authorization or caching system yet, but the system still runs. We can just insert the authorization and caching logic later by registering another interceptor and checking for AuthorizeAttribute or CacheAttribute.
Hopefully this explains the "why."
Sidebar: As Krzysztof Koźmic comments, it's not a DP "best practice" to use a dynamic interceptor like this. In production code, you don't want to have the interceptor running for unnecessary methods, so use an IInterceptorSelector instead.
The reason you would use Castle-DynamicProxy is for what's called Aspect Orientated Programming. It lets you interject code into the standard operation flow of your code without the need to become dependent on the code itself.
A simple example is as always, logging. That you would create a DynamicProxy around a class that you have errors from that it logs the data going into the method and catches any exceptions and then logs the exception.
Using the intercepter your current code has no idea it exists (assuming you have your software built in a decoupled way with interfaces correctly) and you can change the registration of your classes with an inversion of control container to use the proxied class instead without having to change a single line else where in code. Then when you solve the bug you can turn off the proxying.
More advanced usage of proxying can be seen with NHibernate where all of the lazy loading is handled through proxies.