I have two classes and have one to many relationship as shown below
public class User
{
public string Name{get;set;}
public IList<Address> Addresses{get;set}
}
public class Address
{
public string StreetAddress{get;set;}
public User User{get;set;}
}
To add address to user I need to initiate Addresses property in User constructor as
public User()
{
this.Addresses=new List<Address>();
}
Is this scenario good candidate to use DI to initiate List or should I initiate the Address list in constructor as shown.
If the the address data itself is required to construct an instance of User, it may be a candidate for DI. But if's just a matter of making sure the list is instantiated, then your code is correct as-is.
In this case Dependency Injection would be overkill. Dependency Injection is usually used to initialize complex networks of services. Here you are dealing with a network of data objects that map to the piece of world you are translating into code: a composition between User and Address is therefore sufficient, and you must initialize collections in the constructor.
Related
For the sake of this example, I have a "User" class that needs to receive access to my EmailService.
Whenevera a new user instance is created ( var user = new User(emailServiceInstance); ) I do not want EmailService instance to be included as a parameter because not all callers will be aware of it. I want Ninject to inject it.
So normally a binding for the EmailService would look something like this:
kernel.Bind<IEmailService>().To<EmailService>().InSingletonScope();
But I would like to include more parameters in my User class constructor. I would like to pass some parameters and have EmailService injected as well. Is this possible?
From its callers, User class would be instanciated with something like:
var user = new User(firstName,LastName, [notsure])
And then my User class constructor would look like this:
public User(string firstName, stringLastName, EmailService emailService)
First and Lastname would be passed in and email service would be instantiated/injected with Ninject.
Is it possible? What would be the correct syntax to create this binding ?
Neither Constructor Injection nor Property Injection are a good fit for your scenario. In section 4.3 of DIPP&P, Mark Seemann and I state that:
Entities that contain behavior besides their usual set of data members would easily get a wide range of methods, each requiring their own dependencies. Although you might be tempted to use Constructor Injection to inject such dependencies, that leads to a situation where each such entity needs to be created with all of its dependencies, even though only a few may be necessary for a given use case. This complicates testing the logic of an entity, because all dependencies need to be supplied to the constructor, even though a test might only be interested in a few dependencies. Method Injection [...] offers a better alternative.
Using Method Injection, your User entity would become something as follows:
public class User
{
public string FirstName { get; }
public string LastName { get; }
public string PasswordHash { get; }
public User(string firstName, string lastName)
{
this.FirstName = firstName;
this.LastName = lastName;
}
public void ResetPassword(
IEmailService mailService, IPasswordGenerator generator)
{
var password = generator.Generate();
this.PasswordHash = generator.Hash(password);
// Warning: this is just an example, but not a good security practice.
// Mailing passwords is a good way to be shamed on plaintextoffenders.com
mailService.SendMail($#"
Hello {this.FirstName}
We have received new password request for your account.
Your new password is: {password}.");
}
}
Notice that the ResetPassword method does not store its incoming dependencies. This is deliberate and this is what makes Method Injection different from both Constructor Injection and Property Injection. When dependencies are applied to a class after construction (which is what happens with Property Injection), it leads to Temporal Coupling. By letting the method use the dependency, but not store the dependency, it prevents Temporal Coupling from occurring.
A more detailed discussion about Method Injection and how to apply it to classes like entities can be found in section 4.3 of Dependency Injection Principles, Practices, and Patterns.
I'm learning about Domain-Driven-Design and I'm a little confused about entities and injecting domain services into them. I have found this blog and conclusion is that injecting services into entities is a bad idea. I partially agree with that, but what to do in this case:
I have User entity which is an aggregate root, which has Password value object in it. It look like this:
Password value object:
public class Password
{
public string Hash { get; private set; }
public string Salt { get; private set; }
private readonly IHashGeneratorService _hashGeneratorService;
public Password(IHashGeneratorService hashGeneratorService)
{
_hashGeneratorService = hashGeneratorService;
}
public void GenerateHash(string inputString)
{
//Some logic
Salt = hashGeneratorService.GenerateSalt();
Hash = hashGeneratorService.GenerateHash(inputString);
}
}
User entity:
public class User
{
public Password Password { get; private set; }
public User(IHashGeneratorService hashGeneratorService)
{
this.Password = new Password(hashGeneratorService);
}
}
In this case if I create User entity via factory I need to provide IHashGeneratorService implementation to factory constructor or Create() method. After that if my factory is used by, for ex. SomeUserService I have to provide implementation (ex. via ctor injection) to it. And so on...
Honestly it smells form me, as lot of my classess are dependent on hash generator service implementation but only Password class uses it. And it also breaks SRP principle for Password class as I assume.
I've found out some solutions:
Use service locator. But it also smells as it's an anti-pattern and it is hard to test and manage entities if we use it.
Implement hashing alghoritm directly inside Password methods.
Stay with that what I have :) Cons are mentioned above, pros are that my classess are easier to test as I can provide mocked service instead of full implementation.
Personally I tend to refoactor my code to second solution as it does not break SRP (or it does? :)), classess are not dependent of hashing service implementation. Something more?
Or do you have another solutions?
I am quite new to DDD, however I belive that hashing passwords is not a concern of the domain, but a technical concern, just like persistence. The hash service should have it's interface defined in the domain, but it's implementation in the infrastructure layer. The application service would then use the hash service to hash the password and create a Password instance (which should be a value object) before passing it to the User aggregate root.
There might be cases where an aggregate has to use a service like when the dependency resolutions are very complex and domain-specific. In this case, the application service could pass a domain service into the aggregate method. The aggregate would then double-dispatch to the service to resolve references.
For more information you can read the Implementing Domain-Driven Design book written by Vaughn Vernon. He speaks about this around page 362 (Model Navigation), but also at a few other places in the book.
I don't know reasons, why do you consider injection of constructor parameters only. AFAIK, it's a common feature for DI-containers to inject properties or fields. E.g., using MEF you could write something like this:
class SomeUserService : ISomeUserService
{
[Import]
private IHashGeneratorService hashGeneratorService { get; set; }
// ...
}
and inject a dependency only in those types, where you really need it.
I have debated this for a while now and still have not come to a conclusion.
While most examples I see have the factories code in the application layer I tend to think it should be in the domain layer.
Reasons for this:
I sometimes have initial validation done in my factory where I want all creation of objects to go through.
I want this code to be used on all instantiates of my object.
Sometimes an operation requires parameter information which feels unnatural to pass to a constructor.
And a few more not as important reasons.
Are there reasons why this is a bad practice?
Does this break other patterns?
A factory in DDD is just an instance of the factory pattern and as such it should be used where it makes the most sense. Another principle to consider is the information expert pattern which essentially states that behavior should be assigned to classes closest to the information. Therefore, if you have some domain specific rules and logic you would like to enforce, place the factory in the domain layer - after all, the factory creates domain objects. Note however that you may have other types of factories in other layers.
From memory, Eric Evans' book has examples where object factories are very much part of the domain layer.
For me, it makes perfect sense to locate your factories here.
+1 for doing that. Accessibility would be a good reason, I would keep the creational code at least close to the domain model layer. Otherwise users of the domain model will get simply confused how to instantiate it specially when finding restricted access constructors. Actually one sound reason to separate it would be that you have different valid ways to create the same thing e.g. which is the case usually when employing the Abstract Factory.
If I had to separate it I would put it in e.g. a package (in the case of Java) at least the same level of the domain model and ship it always along with it e.g.
upper
--> domain
--> domain_factory
I prefer Factories in the Application Layer.
If you keep the Factories in the Domain Layer, they will not help you when you need complex types as parameters (C# code example):
Application Layer:
//this Factory resides in the Domain Layer and cannot reference anything else outside it
Person person = PersonAggregateFactory.CreateDeepAndLargeAggregate(
string name, string code, string streetName,...
and lots of other parameters...);
//these ones reside in Application Layer, thus can be much more simple and readable:
Person person = PersonAggregateFactory.CreateDeepAndLargeAggregate(CreatePersonCommand);
Person person = PersonAggregateFactory.CreateDeepAndLargeAggregate(PersonDTO);
Domain Layer:
public class Person : Entity<Person>
{
public Address Address {get;private set;}
public Account Account {get;private set;}
public Contact Contact {get;private set;}
public string Name {get;private set;}
public Person(string name, Address address,Account account, Contact contact)
{
//some validations & assigning values...
this.Address = address;
//and so on...
}
}
public class Address:Entity<Address>{
public string Code {get;private set;}
public string StreetName {get;private set;}
public int Number {get;private set;}
public string Complement {get;private set;}
public Address(string code, string streetName, int number, string complement?)
{
//some validations & assigning values...
code = code;
}
}
public class Account:Entity<Account>{
public int Number {get;private set;}
public Account(int number)
{
//some validations & assigning values...
this.Number = number;
}
}
//yout get the idea:
//public class Contact...
Also, there is no obligation on keeping Factories inside the Domain Layer (from Domain Driven Design Quickly):
Therefore, shift the responsibility for creating instances of complex
objects and Aggregates to a separate object, which may itself have
no responsibility in the domain model but is still part of the
domain design. Provide an interface that encapsulates all complex
assembly and that does not require the client to reference the
concrete classes of the objects being instantiated. Create entire
Aggregates as a unit, enforcing their invariants.
As I don't use Factories to load persisted objects into memory, they don't have to be accessible from other layers than Application's. Here's why (from Domain Driven Design Quickly):
Another observation is that Factories need to create new objects
from scratch, or they are required to reconstitute objects which
previously existed, but have been probably persisted to a
database. Bringing Entities back into memory from their resting
place in a database involves a completely different process than
creating a new one. One obvious difference is that the new
object does not need a new identity. The object already has one.
Violations of the invariants are treated differently. When a new
object is created from scratch, any violation of invariants ends
up in an exception. We can’t do that with objects recreated from
a database. The objects need to be repaired somehow, so they
can be functional, otherwise there is data loss.
If builders/factories only have dependencies on domain classes and primitives, place them in the domain layer, otherwise place them outside the domain layer.
CAREFUL with placing 'implementation' in the Domain Layer.
Your domain code doesn't have dependencies. So, you are in trouble if you need to have complex factories.
For example:
// DOMAIN LAYER
public interface IAggregateFactory<TAgg, in TInput>
{
Task<TAgg> CreateAsync(TInput input);
}
public class AvailabilityFactoryParameters
{
public string SomeInputParameter { get; set; }
public string ZipCode { get; set; }
}
// INFRASTRUCTURE/APPLICATION LAYER
public class AvailabilityFactory : IAggregateFactory<GamePredictorAggregate,
GamePredictorFactoryParameters>
{
private readonly HttpClient _httpClient;
public AvailabilityFactory(IHttpClientFactory factory)
{
_httpClient = factory.CreateClient("weatherApi");
}
public async Task<GamePredictorAggregate> CreateAsync(GamePredictorFactoryParameters input)
{
var weather = await _httpClient.GetFromJsonAsync<WeatherDto>($"/weather/{input.ZipCode}");
return new GamePredictorAggregate(weather.CurrentTemperature, input.SomeInputParameter);
}
}
public class WeatherDto
{
public double CurrentTemperature { get; set; }
}
As you can see, now you have a myriad of objects and dependencies available to enrich your factory experience.
So, when you use it in your Application Service, it is easy...
public class GamePredictionService : ApplicationService
{
private readonly IAggregateFactory<GamePredictorAggregate, GamePredictorFactoryParameters> _factory;
public GamePredictionService(IAggregateFactory<GamePredictorAggregate, GamePredictorFactoryParameters> factory)
{
_factory = factory;
}
public async Task CreateNewPredictor(string zipCode, int someOtherParamater)
{
var input = new GamePredictorFactoryParameters();
input.ZipCode = zipCode;
input.SomeInputParameter = someOtherParamater;
var aggregate = await _factory.CreateAsync(input);
// Do your biz operations
// Persist using repository
}
}
Now your application service doesn't need to worry about the internals, and your domain objects need to understand how the factory gives them 'birth.'
Summary: Having your implementation in the Domain layer makes only sense if your factory only needs primitive types and nothing else. In cases where you may need to gather data from external services or other application services' DTOs, you want to move the implementation outside.
The only 'drawback' is that you need to 'inject' the factory into your application service, but that's not a big deal.
I hope this answer helps to clarify 'where to place Factories.'
I'm pretty new to the concept. What I'm trying to do is create a factory that will return an object that is used for repository functions. No problems there. So I create the instance of a concrete factory in main() and store it in a static property of App but my entities are in a separate dll. Does it make sense to pass the repository to each entity class in the constructor? This doesn't feel right. My question is: how is the best make my entities aware of which repository they should be using?
My App partial class looks like
public partial class App : Application
{
private static ICalDataAccess _daqFactory;
public static ICalDataAccess DataAccessFactory
{
set { _daqFactory = value; }
get { return _daqFactory; }
}
}
Maybe a little more code is in order.
public class Widget
{
public string Description { get; set; }
public int ID { get; set; }
private IWidgetRepository _widgetRepository;
public Widget(IWidgetRepository WidgetRepository)
{
_widgetRepository = WidgetRepository;
}
public void Save()
{
_widgetRepository.Save(this);
}
}
Am I doing anything egregious here?
I think the general recommendation is to keep your entities free from persistence concerns. That is, you have some code that retrieves the entities and uses them to perform whatever work needs to be done, resulting in new, deleted or modified entities, which the calling code then submits to the appropriate repository (or asks to be saved if you have something which tracks or detects modified entities, like EF or NHibernate).
That way your entities do not need to know about repositories at all.
I usually create a UnitOfWork helper class which exposes all of my repositories through a "public RepositoryFactory Repositories { get; }" property, so that simply by supplying an instance of the UnitOfWork class I have access to all of my data sources. UnitOfWork can then be injected via IoC to whatever class needs to have data access.
Some recommended reading on this topic:
Persistence Patterns
Discussion on this same topic elsewhere
Your description sounds more like the service locator pattern than dependency injection. Dependency injection typically looks like any object that needs some service object (such as data access) to do its work receives that service as parameter to its constructor.
I've just finished reading "Domain-driven design: tackling complexity in the heart of software" by Eric Evans and I'm attempting to write my first domain-centric application (in C#).
The application will be used by our helpdesk to track the allocation of computers to users.
I've sketched a simple class diagram to reflect part of the domain. It looks like this...
Class diagram showing two classes: Owner and Computer. There is a one-way associate between Computer and Owner named 'Allocate to' http://www.freeimagehosting.net/uploads/183dd57031.jpg
I've also identified my first feature (to allocate a computer to a user) and have written a test for it...
[Test]
public void AllocateToUser()
{
var user = new Owner("user1");
var computer = new Computer("computer1");
computer.Allocate(user);
Assert.AreEqual(user.Username, computer.AllocatedTo.Username);
}
Lastly, I've written code to make the test pass.
public class Computer
{
public Computer(string name)
{
Name = name;
}
public string Name
{ get; private set; }
public Owner AllocatedTo
{ get; private set; }
public void Allocate(Owner owner)
{
AllocatedTo = owner;
}
}
public class Owner
{
public Owner(string username)
{
Username = username;
}
public string Username
{ get; private set; }
}
So far, so good (I think).
However, clearly none of this addresses persistence. I think I need to introduce a repository class for Computer. Something like this perhaps:
public class ComputerRepository
{
public void Store(Computer computer)
{
//Some persistence logic here (possibly using NHibernate?)
}
}
Now I'm stuck. How do ensure that changes made to a computer's allocated user are passed to the repository?
I seem to have the following options:
Modify the implementation of the Allocate method of the Computer class to instanstiate an instance of ComputerRepositry and invoke the Store method.
Create an interface IComputerRepository; modify the constructor of Computer to demand that an instance of a class implemeting IComputerRepository is supplied. Within the Allocate method, call Store against this injected instance.
Create a service (AllocationService) that will wrap up a call to Allocate and Store.
Pass resposibility to the client, forcing two steps for the calling code:
Invoke Allocate on an instance of the Computer class
Instantiate an instance of the ComputerRepository and call Store.
None of these seem satisfactory:
is hard to test, as I'd be instantiating the repository directly within the Computer class.
avoids this problem, by using dependency-injection. However it is still ugly, as I need to pass in some instance of IComputerRepository every time I want to instantiate Computer.
is too procedural, failing to encapsulate the behaviour within domain entity classes.
just seems ugly.
What should I be doing?
Usually I would treat behaviour and persistence as two different concerns and test them separately.
The Domain objects should remain oblivious to the existence of Repositories (though clearly not the other way round).
What we've done in this situation is to create a Controller (or a Service) that is responsible for loading the appropriate objects from their Repositories, invoking the behaviour on the objects then calling the Repositories to persist the updates.
You can then test the controller using a Mock repository to check that the controller is calling the repository with the updated objects.