I am trying to inject properties from ProductCategoryViewModel, which has Title and Id properties into ProductViewModel, which also has Title and Id properties (but for Product) and ProductCategoryTitle,ProductCategoryId for ProductCategory.
Nothing I tried so far works. The default injection overwrites Title and Id props in ProductViewModel and so does FlatLoopValueInjection.
This is such a common use case, is there a premade value injection for it?
I solved this using the following value injection
public class ProductCategoryToProduct : ConventionInjection
{
protected override bool Match(ConventionInfo c)
{
return c.TargetProp.Name.Equals(c.Source.Type.Name + c.SourceProp.Name) && c.SourceProp.Type.Equals(c.TargetProp.Type);
}
}
Related
Need some help trying to solve a problem resolving an implementation of a service at runtime based on a parameter. In other words use a factory pattern with DI.
We have Autofac wired in to our MVC application. I am trying to figure out how we can use a user session variable (Call it Ordering Type) to be used for the Dependency Resolver to resolve the correct implementation of a service.
An example of what we are trying to do.
The application has two "types" of ordering - real eCommerce type of ordering (add stuff to a shopping cart, checkout etc).
The other is called Forecast ordering. Users create orders - but they do not get fulfilled right away. They go through an approval process and then fulfilled.
The bottom line is the data schema and back end systems the application talks to changes based on the order type.
What I want to do is:
I have IOrderManagerService
public interface IOrderManagerService
{
Order GetOrder(int orderNumber);
int CreateOrder(Order order);
}
Because we have two ordering "types" - I have two implementations of the the IOrderManagerService:
public class ShelfOrderManager : IOrderManagerService
{
public Order GetOrder(int orderMumber)
{
...code
}
public int CreateOrder(Order order)
{
...code
}
}
and
public class ForecastOrderManager: IOrderManagerService
{
public Order GetOrder(int orderMumber)
{
...code
}
public int CreateOrder(Order order)
{
...code
}
}
My First question is - in my MVC application - do I register these implementations as?
builder.RegisterType<ShelfOrderManager>().As<IOrderManagerService>();
builder.RegisterType<ForecastOrderManager>().As<IOrderManagerService>();
What we are planning on doing is sticking the user selected ordering type in a users session. When a user wants to view order status - depending on their selected ordering "type" - I need the resolver to give the controller the correct implementation.
public class OrderStatusController : Controller
{
private readonly IOrderManagerService _orderManagerService;
public OrderStatusController(IOrderManagerService orderManagerService)
{
//This needs to be the correct implementation based on the users "type".
_orderManagerService = orderManagerService;
}
public ActionResult GetOrder(int orderNumber)
{
var model = _orderManagerService.GetOrder(orderNumber);
return View(model);
}
}
I've ready about the the delegate factory and this answer explains the concept well.
The problem is the runtime parameters are being used to construct the service and resolve at runtime. i.e.
var service = resolvedServiceClass.Factory("runtime parameter")
All this would do is give me "service" that used the "runtime parameter" in the constructor.
I've looked at Keyed or Named resolution too.
At first I thought I could combine these two techniques - but the controller has the dependency on the interface - not the concrete implementation. (as it should)
Any ideas on how to get around this would be MUCH appreciated.
As it would turn out we were close. #Andrei is on target with what we did. I'll explain the answer below for the next person that comes across this issue.
To recap the problem - I needed to resolve a specific concrete implementation of an interface using Autofac at run time. This is commonly solved by the Factory Pattern - but we already had DI implemented.
The solution was using both. Using the delegate factory Autofac supports, I created a simple factory class.
I elected to resolve the component context privately
DependencyResolver.Current.GetService<IComponentContext>();
versus having Autofac resolve it predominately so I did not have to include IComponentContext in all of my constructors that that will be using the factory.
The factory will be used to resolve the services that are dependent on run time parameters - which means wherever a
ISomeServiceThatHasMultipleImplementations
is used in a constructor - I am going to replace it with ServiceFactory.Factory factory. I did not want to ALSO include IComponentContext wherever I needed the factory.
enum OrderType
{
Shelf,
Forecast
}
public class ServiceFactory : IServiceFactory
{
private readonly IComponentContext _componentContext;
private readonly OrderType _orderType;
public ServiceFactory(OrderType orderingType)
{
_componentContext = DependencyResolver.Current.GetService<IComponentContext>();
_orderType = orderingType;
}
public delegate ServiceFactory Factory(OrderType orderingType);
public T Resolve<T>()
{
if(!_componentContext.IsRegistered<T>())
return _componentContext.ResolveNamed<T>(_orderType.ToString());
return _componentContext.Resolve<T>();
}
}
With the factory written, we also used the Keyed services.
Using my order context -
public interface IOrderManagerService
{
Order GetOrder(int orderNumber);
int CreateOrder(Order order);
}
public class ShelfOrderManager : IOrderManagerService
{
public Order GetOrder(int orderNumber)
{
...
}
public int CreateOrder(Order order)
{
...
}
}
public class ForecastOrderManager : IOrderManagerService
{
public Order GetOrder(int orderNumber)
{
...
}
public int CreateOrder(Order order)
{
...
}
}
The registration of Keyed services:
//register the shelf implementation
builder.RegisterType<ShelfOrderManager>()
.Keyed(OrderType.Shelf)
.As<IOrderManager>();
//register the forecast implementation
builder.RegisterType<ForecastOrderManager>()
.Keyed(OrderType.Shelf)
.As<IOrderManager>();
Register the factory:
builder.RegisterType<IMS.POS.Services.Factory.ServiceFactory>()
.AsSelf()
.SingleInstance();
Finally using it in the controllers (or any other class for that matter):
public class HomeController : BaseController
{
private readonly IContentManagerService _contentManagerService;
private readonly IViewModelService _viewModelService;
private readonly IApplicationSettingService _applicationSettingService;
private readonly IOrderManagerService _orderManagerService;
private readonly IServiceFactory _factory;
public HomeController(ServiceFactory.Factory factory,
IViewModelService viewModelService,
IContentManagerService contentManagerService,
IApplicationSettingService applicationSettingService)
{
//first assign the factory
//We keep the users Ordering Type in session - if the value is not set - default to Shelf ordering
_factory = factory(UIUserSession?.OrderingMode ?? OrderType.Shelf);
//now that I have a factory to get the implementation I need
_orderManagerService = _factory.Resolve<IOrderManagerService>();
//The rest of these are resolved by Autofac
_contentManagerService = contentManagerService;
_viewModelService = viewModelService;
_applicationSettingService = applicationSettingService;
}
}
I want to work out a bit more handling of the Resolve method - but for the first pass this works. A little bit Factory Pattern (where we need it) but still using Autofac to do most of the work.
I would not rely on Autofac for this. IOC is used to resolve a dependency and provide an implementation for it, what you need is to call a different implementation of the same interface based on a decision flag.
I would use a simple factory basically, like a class with 2 static methods and call whichever implementation you need need to when you know what the decision is. This gives you the run-time resolver you are after. Keep it simple I'd say.
This being said it seems there is another option. Have a look at the "select by context" option, maybe you can redesign your classes to take advantage of this: http://docs.autofac.org/en/latest/faq/select-by-context.html
I have a question regarding creating a class diagram where I have used dependency injection.
I have following code example:
public class ReservationController : ApiController
{
private readonly IGetReservationService _getReservationService;
public ReservationController(IGetReservationService getReservationService)
{
_getReservationService = getReservationService;
}
// GET list of all reservations
public List<ReservationViewModel> GetReservations()
{
return _getReservationService.GetReservations();
}
// GET single reservation by id
public List<ReservationViewModel> GetReservation(string reservationNumber)
{
return _getReservationService.GetReservation(reservationNumber);
}
}
Here you see that the controller (ReservationController) getting the IGetReservationService injected in the constructor. When creating the relationship between the controller and the interface, do you then use a dependency or an association?
My guess is that it should be a dependency since we are using dependency injection?
Good day.
Yes, this is a dependency. An association is used if you have object references (e.g. for a property).
I do find a related question with this and I exactly have the same problem. link : Grails FindBy* with an inteface property
Yes, we can't change the Interface property to an abstract property.
I've read that findBy* can't handle interface property but any graceful tips on how we can proceed on this?
As for the models:
interface InterfaceClass {
//method
}
class EnumClass implements InterfaceClass {
//implementation of method
}
class NonEnumDomain {
InterfaceClass interfaceClass
}
Going back to the issue, also regarding the sited link regarding findBy limitations.
NonEnumDomain.findByInterfaceClass(....) won't work.
In case it's needed for the community to know: we did some UserType on these interface properties since it's an Enum properties.
Thanks
Here I'm assuming that you have the full control over the InterfaceClass and for the desired property it has getter and setter methods declared.
So let's say you would like to have two properties named: name and description in your interface class. Create the getter and setter method declaration there and don't declare the properties there.
interface InterfaceClass {
String getName()
String getDescription()
void setName(String name)
void setDescription(String description)
}
EnumClass class would contain those properties and will implement the InterfaceClass.
class EnumClass implements InterfaceClass {
String name
String description
String getName() {
return name
}
void setiName(String name) {
this.name = name
}
String getDescription() {
return description
}
void setDescription(String description) {
this.description = description
}
}
Now to make the finder methods work for your InterfaceClass, you just have to add the interfaceClass property in your domain class to embedded properties list.
class NonEnumDomain {
InterfaceClass interfaceClass
static embedded = ['interfaceClass']
}
To save the instance of NonEnumDomain:
new NonEnumDomain(interfaceClass: new EnumClass(name: "Sandeep Poonia", description: "Interface property in domain class")).save(failOnError: true, flush: true)
and to find an instance using finders:
NonEnumDomain.findByInterfaceClass(new EnumClass(name: "Sandeep Poonia", description: "Interface property in domain class"))
Definition of embedded keyword:
Supports embedding domain components into domain classes. An embedded
component does not store its data in its own table as a regular domain
class relationship does. Instead, the data is included in the owner's
table. The embedded component class is typically declared in the same
source file as the owning class or in its own file under src/groovy.
Constraints can also be applied over properties of embedded components
using Validateable annotation.
Using Specflow's basic dependency injection, it is possible to inject a dynamic context object as below.
This saves having to use the dictionary which I find clunky, are there drawbacks to this approach?
public class TestClass
{
private readonly dynamic context;
public TestClass(ExpandoObject context)
{
this.context = context;
}
[Given(#"I have a file")]
public void GivenIHaveAFile()
{
context.FilePath = #".\Folder\File";
}
[When(#"I use the file")]
public void GivenIHaveAFile()
{
var fileContents = File.ReadAllText(context.FilePath);
}
}
The drawbacks are only those that you get with using dynamic objects in general. You'll get no intellisense and won't be able to add any behaviour to your object.
Personally I prefer to use specific classes to handle passing state between steps as these objects can then be assigned behaviour as well as holding data, but YMMV.
In place of the generic dictionary though this seems reasonable, as it at least avoids the casting.
I have a structuremap configuration that has me scratching my head. I have a concrete class that requires a interfaced ui element which requires an interfaced validation class. I want the outer concrete class to get the default ui element, but get a concrete-class-specific validation object. Something like this:
class MyView
{
IPrompt prompt
}
class GenericPrompt : IPrompt
{
IValidator validator
}
class MyValidator : IValidator
{
bool Validate() {}
}
How can I configure structuremap with the Registry DSL to only use MyValidator when creating dependencies for MyView. (And assumedly using BobsValidator when creating dependencies for BobsView)
Are you getting MyView (and BobsView) from the container? Can we assume that they will all take an instance of IPrompt?
One approach would be to register all of your validators with a name that matches the names of your view. You could implement your own type scanner that just removes the Validator suffix:
public class ValidatorScanner : ITypeScanner
{
public void Process(Type type, PluginGraph graph)
{
if (!typeof (IValidator).IsAssignableFrom(type)) return;
var validatorName = type.Name.Replace("Validator", "");
graph.AddType(typeof(IValidator), type, validatorName);
}
}
Now, if you assume an IPrompt will always be requested by a View that follows that naming convention, your registry could look like:
public class ValidatorRegistry : Registry
{
public ValidatorRegistry()
{
Scan(scan =>
{
scan.TheCallingAssembly();
scan.With<ValidatorScanner>();
});
ForRequestedType<IPrompt>().TheDefault.Is.ConstructedBy(ctx =>
{
var viewName = ctx.Root.RequestedType.Name.Replace("View", "");
ctx.RegisterDefault(typeof(IValidator), ctx.GetInstance<IValidator>(viewName));
return ctx.GetInstance<GenericPrompt>();
});
}
}
To retrieve your view with the appropriate validator, you would have to request the concrete type:
var view = container.GetInstance<MyView>();
Note that this will only work if you are retrieving your view with a direct call to the container (service location), since it depends on the "Root.RequestedType". Depending on how you plan to get your views, you might be able to walk up the BuildStack looking for a View (instead of assuming it is always Root).