I have a small app (Win Forms) where I have two different repositories (SQL Server and Redis) both implementing a interface IFilterRepo.
I also have a service class that depends on the IFilterRepo. The client (the Win Form) call the service to access filter data.
I want the client to have two radio buttons where a user can choose which repo to use. And here comes my dilemma. How should I tell the service which concrete class to instantiate as IFilterRepo? I mean, ALL Unity registrations and references to it shall be done in the composition root. Is that "rule" really possible in this case?
This is a common question, and the answer is generally to use an Abstract Factory.
Here is a good article on the subject (I link this all the time, but I didn't write it):
http://blog.ploeh.dk/2012/03/15/ImplementinganAbstractFactory/
As noted in the article, you can make the factory part of the composition root, so that calling container.Resolve() inside the factory doesn't violate that rule.
Edit
You would register different implementations of the service using a name (string):
http://msdn.microsoft.com/en-us/library/ff648211.aspx
myContainer.RegisterType<IMyService, CustomerService>("Customers");
And then your factory would resolve by that name:
public IFilterRepo Create(string myName)
{
return myContainer.Resolve<IFilterRepo>(myName);
}
Edit 2
The question you asked in your last comment is a bit much to answer here, but in brief: your factory itself would implement an interface, and would be resolved and registered via the container.
As a general matter, I would not recommend accessing a repository directly from the code behind--I would at least look at having a layered architecture (or better, an Onion architecture, which works very well with DI).
Finally, I have not done WinForms development in years, but I don't think it fits perfectly with using a container/Composition Root, since you don't have full control over the lifecycle of your objects (you can't inject services into your form constructors). The same is true of ASP.Net Webforms. So you may have to use property injection for your factory and other services needed in your form, or just resolve the factory directly via calling a static instance of the container (container.Resolve()). This is imperfect, and goes against the idea of having a Composition Root, and more toward service location.
You might google keywords "Unity WinForms" and/or "[OtherDIFramework] Winforms" to get some ideas of how to structure your code.
Related
In an application using the DDD concepts I am in doubt about who could inject (dependencies) into the constructor of a given class if there is any standard for it.
For example, between the Application, Domain, and Repository layers.
1) A ClientAppService (Application layer) that needs to inject user, should I inject UserApplicationService and from it call UserService (Domain) or inject UserService directly in ClientApplicationService?
2) In the ClientService (domain) should I inject UserService and from it call UserRepository or could I inject UserRepository directly into ClientService?
I'm concerned about cyclic reference if I'm injecting peer classes.
But I also think that I should not inject the Repository of another Entity, because often the methods of the repository have a rule in the service that must be called previously.
Has anyone ever had this question, how do you usually handle it?
Thinking about separation of concerns and allocation of responsibilities, you should inject exactly what your artifact depends upon. This may sound a little obvious, but it goes a little deeper.
Considering your (2) example:
In the ClientService (domain) should I inject UserService and from it call UserRepository or could I inject UserRepository directly into ClientService?
You probably should first ask yourself which capability does your ClientService depend upon?
If it (ClientService) cares about being able to find user from information it (ClientService) currently possesses, it should probably receive the UserRepository directly and be able to find the user on its own.
If it (ClientService) needs a user, but it doesn't possess the information needed to find the user (this information is currently on application layer level), maybe ClientService should receive the User domain object directly, with the repository being used straight from application level.
If it (ClientService) needs some kind of domain-relevant functionality from UserService as part of its operation, then, in that case, the UserService might be directly injected into ClientService.
Other possible discussion on this topic might whether you really need all those Domain Services of if you would be better calling rule-rich Entities/Aggregates straight from the Application Layer, it might make your overall design, injection patterns and boundaries simpler.
Also, many times, you might want to inject factories for your artifact rather than the instantiated ones directly.
Another point might be made about:
But I also think that I should not inject the Repository of another Entity, because often the methods of the repository have a rule in the service that must be called previously.
This might be evidence of some confusion inside your domain. The role of a repository should be around the lines of "finding your domain entity from the universe of possible entities". In that sense, a UserRepository enables you to find users from the users existing in your universe so it should be a pretty isolated operation and shouldn't depend on services or other entities. If a user exists, it should be "findable" (and persistable, as it goes both ways) from the UserRepository.
In that case, you shouldn't worry about "injecting UserRepository in ClientService" from a dogmatic point of view. If the operation in your client service needs to find and use a User Entity, it should be alright for you to do so. What you might worry about is whether your entities/aggregates are well designed or if you have some kind of misplaced responsibilities that might be triggering this "feeling" of "I shouldn't be injecting this into that".
Domain Entities and Value Objects almost never use constructor injection.
This is motivated by separation of concerns; the responsibility of the objects in the domain model is to manage their own in memory representations.
Other capabilities that they may need to do their work are passed to them as arguments.
The typical mechanism for this is the "domain service", described by Evans in chapter 5 of the blue book.
To sketch an example - suppose my order aggregate needs to update its quote when the line items change. I might pass in as an argument an interface that accepts a SKU and returns a Price. As far as Order is concerned, that lookup is happening "somewhere else". It doesn't care about the details. The implementation might load up another aggregate to look up its current state, or send a message to some remote system, or hard code an answer.
Domain Service implementations will often have injected dependencies on capabilities provided by the application or infrastructure layers.
I'm quite new to Symfony 2 and I'm moving to advanced topics like services. When should an object be a service?
For example, say that you have a facade object for making a call to a REST service. This class needs a username and password. Would it be correct modeling that class as a global service? Even if it's used only in a portion of the whole project?
# app/config/config.yml
parameters:
my_proxy.username: username
my_proxy.password: password
services:
my_proxy:
class: Acme\TestBundle\MyProxy
arguments: [%my_proxy.username%, %my_proxy.password%]
Definition taken from the Symfony2 glossary:
A Service is a generic term for any PHP object that performs a specific task. A service is usually used "globally", such as a database connection object or an object that delivers email messages. In Symfony2, services are often configured and retrieved from the service container. An application that has many decoupled services is said to follow a service-oriented architecture.
I think your example is a perfect candidate for a service.
You don't want to copy construction code to all places you need your API client. It's better to delegate this task to the dependency injection container.
This way it's easier to maintain (as construction happens in one place and it's configurable).
It's also more flexible as you can easily change the API client class without affecting code which uses it (as long as it implements the same interface).
I don't think there's a golden rule. But basically all classes implementing a task are good candidates for a service. Entities on the other hand are not as they're most often just data holders.
I always recommend Fabien's series of articles on the subject: http://fabien.potencier.org/article/11/what-is-dependency-injection
Yes, because this will spare you the configuration part. You're not going to fetch the username and password and give it to the constructor each time you need this class.
Ok, so the problem is:
I've got some 'order' entity, and it has 'status' property. On changing status, i wanted some other objects to be informed of this event, so i've decided to use Observer pattern. One of the observers notifies clients via email. Now i want to render Email text's from some of the twig templates. As i get from the Book, rendering templates in controllers are done with 'templating' service.
So the question as it follows: How can i access 'templating' service in my Observer class?
Specification:
I was advised, to implement my Observer as a service, but i'm not sure 'bout that. I've tried to solve this problem, and here is my options:
Use Registry. Solution that is straight and hard as rail. I guess it misses the whole point of DI and Service Container. Huge plus of this solution, is that i can access all common services from any point of my application.
To pass needed services from the context via constructor, or via setters. This is more like in Sf2 spirit. There comes another list of problems, which are not related to this question field.
Use observers as a service. I'm not really sure 'bout this option 'cos, in the book it is written, that service is a common functionality, and i don't think that observing entity with number of discrete properties is a common task.
I'm looking for a Sf2 spirit solution, which will be spread over whole project, so all answers with an explanation are appreciated.
As with any other service in a Symfony2 project, you can access it from within other classes through the dependency injector container. Basically what you would do is register your observer class as a service, and then inject the templating service into your observer service. See the docs for injecting services.
If you're not familiar with how Symfony handles dependency injection, I'd suggest reading that entire chapter of the documentation - it's very helpful. Also, if you want to find all the services that are registered for application, you can use the console command container:debug. You can also append a service name after that to see detailed info about the service.
Edit
I read your changes to the question, but still recommend going down the DI route. That is the Symfony2 spirit :) You're worried that your observer isn't common enough to be used as a service, but there's no hard rule saying "You must use this piece of code in X locations in order for it to be 'common'".
Using the DIC comes with another huge benefit - it handles other dependencies for you. Let's say the templating service has 3 services injected into itself. When using the DIC, you don't need to worry about the templating service's dependencies - they are handled for you. All you care about is telling it "inject the templating service into this other service" and Symfony takes care of all the heavy lifting.
If you're really opposed to defining your observer as a service, you can use constructor or setter injection as long as you're within a container-aware context.
I have a solution with several projects (MyApp.Data, MyApp.BLL, MyApp.Web). I register types in Global.asax file in MyApp.Web (main web application):
builder.RegisterType<SomeService1>().As<ISomeService1>().InstancePerHttpRequest();
builder.RegisterType<SomeService2>().As<ISomeService2>().InstancePerHttpRequest();
//...etc
And I wonder whether it's a bad practice to register types and their scope using attributes in the other assemblies (for example, in MyApp.BLL). See below:
[Dependency(typeof(ISomeService1), ComponentLifeStyle.Transient)]
public class SomeService1 : ISomeService1
{
//methods and properties go here
}
Using local attributes or other ways to indicate wiring for a DI Container tightly couples the service to the DI Container, so I don't think that's a good idea.
Additionally, it may constrain your future options. If, for example, you specify the lifestyle scope, you can't reuse the service with a different scope.
In general, you should compose the application in a Composition Root (global.asax), which gives you a single location with a clearly defined responsibility where all classes are composed.
That would be much more manageable and maintainable that spreading the configuration data all over your classes.
As your question implies, it makes some sense to delegate responsibility for registration to the assembly that knows what needs to be registered. For example, if you
use the SolrNet library, it provides a method that performs component registration, to encapsulate the knowledge of what needs to be registered and to spare the library's consumer from having to learn all about the library before getting started.
However, there is a potential issue with this approach. Would your registration requirements change if you used the dependent assemblies in other applications? For example, would it make sense to register something as ComponentLifeStyle.HttpRequestScoped and then use it in a non-Web application? By delegating registration to the dependency, you are coupling the dependency to its consumer's registration requirements (and to its choice of IoC container).
Autofac (I can't speak for other IoC containers) provides a way round this. It enables you to override registrations so that the most recently registered component is used when a service is resolved. This means that you can call a library's registration method and then register your own services to override the defaults.
There is another problem with your proposed attribute-based registration - it doesn't enable you to specify a lambda expression as a component creator. How would you implement a registration like this with attributes?
builder.Register(c => new A(c.Resolve<B>()));
It might be preferable to define an IRegistrar interface, and then use reflection to search all loaded assemblies for implementations and invoke them. Perhaps something like this:
public interface IRegistrar
{
void RegisterComponents();
}
In an effort to understand MVC 2 and attempt to get my company to adopt it as a viable platform for future development, I have been doing a lot of reading lately. Having worked with ASP.NET pretty exclusively for the past few years, I had some catching up to do.
Currently, I understand the repository pattern, models, controllers, data annotations, etc. But there is one thing that is keeping me from completely understanding enough to start work on a reference application.
The first is the Service Layer Pattern. I have read many blog posts and questions here on Stack Overflow, but I still don't completely understand the purpose of this pattern. I watched the entire video series at MVCCentral on the Golf Tracker Application and also looked at the demo code he posted and it looks to me like the service layer is just another wrapper around the repository pattern that doesn't perform any work at all.
I also read this post: http://www.asp.net/Learn/mvc/tutorial-38-cs.aspx and it seemed to somewhat answer my question, however, if you are using data annotations to perform your validation, this seems unnecessary.
I have looked for demonstrations, posts, etc. but I can't seem to find anything that simply explains the pattern and gives me compelling evidence to use it.
Can someone please provide me with a 2nd grade (ok, maybe 5th grade) reason to use this pattern, what I would lose if I don't, and what I gain if I do?
In a MVC pattern you have responsibilities separated between the 3 players: Model, View and Controller.
The Model is responsible for doing the business stuff, the View presents the results of the business (providing also input to the business from the user) while the Controller acts like the glue between the Model and the View, separating the inner workings of each from the other.
The Model is usually backed up by a database so you have some DAOs accessing that. Your business does some...well... business and stores or retrieves data in/from the database.
But who coordinates the DAOs? The Controller? No! The Model should.
Enter the Service layer. The Service layer will provide high service to the controller and will manage other (lower level) players (DAOs, other services etc) behind the scenes. It contains the business logic of your app.
What happens if you don't use it?
You will have to put the business logic somewhere and the victim is usually the controller.
If the controller is web centric it will have to receive its input and provide response as HTTP requests, responses. But what if I want to call my app (and get access to the business it provides) from a Windows application which communicates with RPC or some other thing? What then?
Well, you will have to rewrite the controller and make the logic client agnostic. But with the Service layer you already have that. Yyou don't need to rewrite things.
The service layer provides communication with DTOs which are not tied to a specific controller implementation. If the controller (no matter what type of controller) provides the appropriate data (no mater the source) your service layer will do its thing providing a service to the caller and hiding the caller from all responsibilities of the business logic involved.
I have to say I agree with dpb with the above, the wrapper i.e. Service Layer is reusable, mockable, I am currently in the process of including this layer inside my app... here are some of the issues/ requirements I am pondering over (very quickly :p ) that could be off help to youeself...
1. Multiple portals (e.g. Bloggers portal, client portal, internal portal) which will be needed to be accessed by many different users. They all must be separate ASP.NET MVC Applications (an important requirement)
2. Within the apps themselves some calls to the database will be similar, the methods and the way the data is handled from the Repository layer. Without doubt some controllers from each module/ portal will make exactly or an overloaded version of the same call, hence a possible need for a service layer (code to interfaces) which I will then compile in a separate class project.
3.If I create a separate class project for my service layer I may need to do the same for the Data Layer or combine it with the Service Layer and keep the model away from the Web project itself. At least this way as my project grows I can throw out the data access layer (i.e. LinqToSql -> NHibernate), or a team member can without working on any code in any other project. The downside could be they could blow everything up lol...