public interface IStuff
{
public int A { get; }
public event EventHandler StuffHappened;
}
public class Stuff : IStuff
{
public int A { get; private set; }
public event EventHandler StuffHappened;
}
public class WorkerA : IStuff
{
Stuff stuff = new();
public int A => stuff.A;
public event EventHandler StuffHappened
{
add => stuff.StuffHappened += value;
remove => stuff.StuffHappened -= value;
}
}
public class WorkerB : IStuff
{
// same as WorkerA
}
public class WorkerC : IStuff
{
// same as WorkerA
}
If I have several classes that need to implement the same interface in the same way, but they can't inherit the same base class (perhaps they are already inheriting something else), is there a way to write a helper class that implements the interface and just have that as a property in the several classes that need to implement the interface and have those classes implement the interface by wrapping the helper class WITHOUT having to wrap every single property of the helper class? Wrapping events is especially the worst! I find myself in this situation so often that it's worth my time to write this post. Thanks
Related
Single interface: IDoSomething {...}
Two classes implement that interface:
ClassA : IDoSomething {...}
ClassB : IDoSomething {...}
One class uses any of those classes.
public class DummyClass(IDoSomething doSomething) {...}
code without Autofac:
{
....
IDoSomething myProperty;
if (type == "A")
myProperty = new DummyClass (new ClassA());
else
myProperty = new DummyClass (new ClassB());
myProperty.CallSomeMethod();
....
}
Is it possible to implement something like that using Autofac?
Thanks in advance,
What you are looking for is, as I remember, the Strategy Pattern. You may have N implementations of a single interface. As long you register them all, Autofac or any other DI framework should provide them all.
One of the options would be to create a declaration of the property with private setter or only getter inside Interface then implement that property in each of the class. In the class where you need to select the correct implementation, the constructor should have the parameter IEnumerable<ICommon>.
Autofac or any other DI frameworks should inject all possible implementation. After that, you could spin foreach and search for the desired property.
It may look something like this.
public interface ICommon{
string Identifier{get;}
void commonAction();
}
public class A: ICommon{
public string Identifier { get{return "ClassA";} }
public void commonAction()
{
Console.WriteLine("ClassA");
}
}
public class A: ICommon{
public string Identifier { get{return "ClassB";} }
public void commonAction()
{
Console.WriteLine("ClassA");
}
}
public class Action{
private IEnumerable<ICommon> _common;
public Action(IEnumerable<ICommon> common){
_common = common;
}
public void SelectorMethod(){
foreach(var classes in _common){
if(classes.Identifier == "ClassA"){
classes.commonAction();
}
}
}
}
I have an autofac DI in my project.
I want to expose an interface by conventional which all other interfaces of my project will inherit from. Is it possible to automatically register the components of the inherited interfaces at start up level? For example:
Public interface IConvetionInterface {}
public interface IImplementationA:IConvetionInterface
{
public void DoSomethingA();
}
public interface IImplementationB:IConvetionInterface
{
public void DoSomethingB();
}
Injecting through constructor;
public class ConsumerA
{
private readonly IImplementationA _a;
public DealerRepository(IImplementationA A)
{
_a= A;
}
public Act()
{
_a.DoSomethingA();
}
}
How do I register IConvetionInterface to make all its dependencies resolve in Autofac.
I have been able to come up with this solution by using autofac Assembly Scanning Configuration as provided in their documentation page Autofac Documentation Page
I have an open generic interface
public interface IRepository<TEntity, TPrimaryKey> where TEntity : class, IEntity<TPrimaryKey>
{ }
Implemented by
public class Repository<TEntity, TPrimaryKey> : RepositoryBase<TEntity, TPrimaryKey>
where TEntity : class, IEntity<TPrimaryKey>{}
Then, I created an empty interface
public interface IConventionDependency
{
}
This method was called to register my components at startup level:
public static void RegisterAPSComponents(ContainerBuilder builder)
{
builder.RegisterType<APSContext>().InstancePerRequest();
builder.RegisterGeneric(typeof(Repository<,>)).As(typeof(IRepository<,>)).InstancePerLifetimeScope();
builder.RegisterAssemblyTypes(typeof(IConventionDependency).Assembly).AssignableTo<IConventionDependency>().As<IConventionDependency>().AsImplementedInterfaces().AsSelf().InstancePerLifetimeScope();
}
By the above registration, any interface that inherits from IConventionDependency will be registered automatically in the container.
example:
create an interface:
public interface IDealerRepository : IConventionDependency
{
List<Dealers> GetDealers();
}
then Implement the interface :
public class DealerRepository : IDealerRepository
{
private readonly IRepository<VTBDealer, int> _repository;
public DealerRepository(IRepository<VTBDealer, int> repository)
{
_repository = repository;
}
public List<Dealers> GetDealers()
{
return _repository.GetAllList().MapTo<List<Dealers>>();
}
}
in conclusion, without explicitly registering IDealerRepository, it gets resolved in MVC Controller constructor.
I am building an EntityFramework/WebApi back end.
I want to decouple my WebApi from the Entity Framework, and utilize Dependency Injection so I can swap out the "data source" for the web API.
I have been looking at the Unit of Work and Repository patterns.
I also want to use breezejs.
The breezejs TempHire samples has been alot of help, so I will use this as an example for my question -
https://github.com/Breeze/breeze.js.samples/tree/master/net/TempHire
In this sample, on the data side we have the UnitOfWork class -
public class UnitOfWork
{
private readonly EFContextProvider<TempHireDbContext> _contextProvider;
public UnitOfWork()
{
_contextProvider = new EFContextProvider<TempHireDbContext>();
StaffingResources = new Repository<StaffingResource>(_contextProvider.Context);
Addresses = new Repository<Address>(_contextProvider.Context);
// .. etc.
}
public IRepository<StaffingResource> StaffingResources { get; private set; }
public IRepository<Address> Addresses { get; private set; }
// .. etc.
public SaveResult Commit(JObject changeSet)
{
return _contextProvider.SaveChanges(changeSet);
}
}
Then on the WebApi side, it uses it like this -
[BreezeController]
[Authorize]
public class ResourceMgtController : ApiController
{
private readonly UnitOfWork _unitOfWork = new UnitOfWork();
[HttpPost]
public SaveResult SaveChanges(JObject saveBundle)
{
return _unitOfWork.Commit(saveBundle);
}
// ... etc.
}
I would like to refactor to something like this, so that I could swap out the back end.
public class UnitOfWork : IUnitOfWork
public class ResourceMgtController : ApiController
{
private readonly IUnitOfWork _unitOfWork;
public ResourceMgtController(IUnitOfWork unitOfWork) {
this._unitOfWOrk = unitOfWork; // Dependency Injected...
}
// ... etc.
}
What I can't wrap my head around, is how I can make it generic. The breeze client needs a method like this -
[HttpPost]
public SaveResult SaveChanges(JObject saveBundle)
{
return _unitOfWork.Commit(saveBundle);
}
And I can't put this in IUnitOfWork -
SaveResult SaveChanges(JObject saveBundle)
And really keep it decoupled from breeze, be able to swap out the back end for another backend. Am I attempting the abstraction at the wrong point? I guess if I want breeze on the client I will need to couple it on the backend?
You clearly can define an interface with that method:
public interface IUnitOfWork {
...
SaveResult SaveChanges(JObject saveBundle); // no problem
}
I suspect that you are objecting to the fact that both SaveResult and JObject are classes defined by libraries (Breeze.ContextProvider and Newtonsoft.Json.Linq respectively) you'd rather not reference somewhere.
These references wouldn't bother me any more than I mind referencing System.Linq to get IQueryable. In fact, a test double of SaveResult (a public class of Breeze.ContextProvider) is trivially easy to construct. Here is its definition (and the definition of KeyMapping, its only non-native dependent type):
public class SaveResult
{
public List<object> Entities;
public List<KeyMapping> KeyMappings;
public List<object> Errors;
}
public class KeyMapping
{
public string EntityTypeName;
public object TempValue;
public object RealValue;
}
But if Breeze and Newtonsoft.Json references are that noxious to you and you're willing to surrender some type safety, you can always create the interface like this:
public interface IUnitOfWork {
...
object SaveChanges(object saveBundle); // no safety, no problem
}
Then in your concrete UnitOfWork you add a suitable overload:
public object IUnitOfWork.SaveChanges(object saveBundle)
{
return SaveChanges((JObject) saveBundle);
}
public SaveResult SaveChanges(JObject saveBundle)
{
return _contextProvider.SaveChanges(saveBundle);
}
... and Bob's your uncle.
Yes, I did try it (in DocCode); worked fine for me.
I read lots of articles, And found that lots of people use INotifyPropertyChanged in ViewModel either Model as well. So, I am confused about INotifyPropertyChanged where to use.
A popular approach is to use a base class which Implements InotifyPropertyChanged interface and then inherit this base class in your View Model.
example:
public class NotifyPropertyBase : INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged;
public void OnPropertyChanged(string propertyName)
{
if (PropertyChanged != null)
{
PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
}
}
}
Then inherit the base class in the view model:
class MainViewModel : NotifyPropertyBase
Finally, raise the OnPropertyChanged event in the property setter of your view model passing in the property name string as the parameter:
private string _name;
public string Name
{
get { return _name; }
set
{
_name= value;
OnPropertyChanged("Name");
}
}
Now your UI should update at run time provided the binding is declared correctly in the Xaml.
I'd like to implement the Decorator pattern in one of my Mvx projects. That is, I'd like to have two implementations of the same interface: one implementation that is available to all of the calling code, and another implementation that is injected into the first implementation.
public interface IExample
{
void DoStuff();
}
public class DecoratorImplementation : IExample
{
private IExample _innerExample;
public Implementation1(IExample innerExample)
{
_innerExample = innerExample;
}
public void DoStuff()
{
// Do other stuff...
_innerExample.DoStuff();
}
}
public class RegularImplementation : IExample
{
public void DoStuff()
{
// Do some stuff...
}
}
Is it possible to wire up the MvvmCross IoC container to register IExample with a DecoratorImplementation containing a RegularImplementation?
It depends.
If DecoratorImplementation is a Singleton, then you could do something like:
Mvx.RegisterSingleton<IExample>(new DecoratorImplementation(new RegularImplementation()));
Then calls to Mvx.Resolve<IExample>() will return the instance of DecoratorImplementation.
However, if you need a new instance, unfortunately the MvvmCross IoC Container doesn't support that. It would be nice if you could do something like:
Mvx.RegisterType<IExample>(() => new DecoratorImplementation(new RegularImplementation()));
Where you'd pass in a lambda expression to create a new instance, similar to StructureMap's ConstructedBy.
Anyway, you may need to create a Factory class to return an instance.
public interface IExampleFactory
{
IExample CreateExample();
}
public class ExampleFactory : IExampleFactory
{
public IExample CreateExample()
{
return new DecoratorImplementation(new RegularImplementation());
}
}
Mvx.RegisterSingleton<IExampleFactory>(new ExampleFactory());
public class SomeClass
{
private IExample _example;
public SomeClass(IExampleFactory factory)
{
_example = factory.CreateExample();
}
}