I have an mvc controller which has a helper class injected into it. I would like to convert from a viewmodel to a dto using automapper. most of the properties are simple mappings but one involves calling the helper class with a parameter from the viewmodel. Ideally I would want to do something like this:
Mapper.CreateMap<TheViewModel, TheDto>()
.ForMember(dest => dest.Url, o => o.MapFrom(src => _urlHelper.GenerateUrlFromUsername(src.Username)));
...but I cannot because I cannot access a non-static field.
What is the best approach?
EDIT:
OK, so I have a custom resolver but how do I hook this in to my IoC container?
public class CustomResolver : ValueResolver<TheViewModel, string>
{
private readonly IUrlHelper _urlHelper;
public CustomResolver(IUrlHelper urlHelper)
{
_urlHelper = urlHelper;
}
protected override string ResolveCore(TheViewModel source)
{
return _urlHelper.GenerateUrlFromUsername(source.Username);
}
}
Use a custom resolver in this case:
http://automapper.codeplex.com/wikipage?title=Custom%20Value%20Resolvers
Custom resolvers can be instantiated from a container, so you can get whatever instance fields of services you need.
Related
I'm looking to use the sluggerInterface in a class. But I want to keep:
public function __construct()
{
}
So I want to use sluggerInterface in my class without adding any argument in my constructor. (this is in order to automatically create 1 slug when creating an object).
So I want a code different from this one:
use Symfony\Component\String\Slugger\SluggerInterface;
class MyService
{
private $slugger;
public function __construct(SluggerInterface $slugger)
{
$this->slugger = $slugger;
}
public function someMethod()
{
$slug = $this->slugger->slug('...');
}
}
Thank you !
You do not want to use autowiring in your constructor ?
You could just create a new slugger, for example with Symfony\Component\String\Slugger\AsciiSlugger;
$slugger = new AsciiSlugger();
$slugger->slug('Please slug this.')->toString();
Or you could also use autowiring with another method using #required annotation (or attribute #[Required] for PHP 8+)
private $slugger;
#[Required]
public function setSlugger(SluggerInterface $slugger): void
{
$this->slugger= $slugger;
}
this is in order to automatically create 1 slug when creating an object
You may also want to look into event listener, using doctrine event prePersist to slug your entity when persisted could be another idea.
Finally, gedmo doctrine-extensions sluggable may interest you as well.
I am trying to inject the IApplicationConfigurationSection implementation into this MVC5 Controller, so that I can have access to some of the information (various strings) from my web.config custom section in all of my views:
public class BaseController : Controller
{
public IApplicationConfigurationSection AppConfig { get; set; }
public BaseController()
{
ViewBag.AppConfig = AppConfig; // AppConfig is always null
}
}
I want to use setter injection so I don't have to clutter up my derived Controller constructors with parameters that they don't really care about.
Note: If there is a better way to inject base class dependencies, please let me know. I admit I may not be on the right track here.
In my Global.asax I load my StructureMap configurations:
private static IContainer _container;
protected void Application_Start()
{
_container = new Container();
StructureMapConfig.Configure(_container, () => Container ?? _container);
// redacted other registrations
}
My StructureMapConfig class loads my registries:
public class StructureMapConfig
{
public static void Configure(IContainer container, Func<IContainer> func)
{
DependencyResolver.SetResolver(new StructureMapDependencyResolver(func));
container.Configure(cfg =>
{
cfg.AddRegistries(new Registry[]
{
new MvcRegistry(),
// other registries redacted
});
});
}
}
My MvcRegistry provides the mapping for StructureMap:
public class MvcRegistry : Registry
{
public MvcRegistry()
{
For<BundleCollection>().Use(BundleTable.Bundles);
For<RouteCollection>().Use(RouteTable.Routes);
For<IPrincipal>().Use(() => HttpContext.Current.User);
For<IIdentity>().Use(() => HttpContext.Current.User.Identity);
For<ICurrentUser>().Use<CurrentUser>();
For<HttpSessionStateBase>()
.Use(() => new HttpSessionStateWrapper(HttpContext.Current.Session));
For<HttpContextBase>()
.Use(() => new HttpContextWrapper(HttpContext.Current));
For<HttpServerUtilityBase>()
.Use(() => new HttpServerUtilityWrapper(HttpContext.Current.Server));
For<IApplicationConfigurationSection>()
.Use(GetConfig());
Policies.SetAllProperties(p => p.OfType<IApplicationConfigurationSection>());
}
private IApplicationConfigurationSection GetConfig()
{
var config = ConfigurationManager.GetSection("application") as ApplicationConfigurationSection;
return config; // this always returns a valid instance
}
}
I have also "thrown my hands up" and tried using the [SetterProperty] attribute on the BaseController - that technique failed as well.
Despite my best efforts to find a solution, the AppConfig property in my controller's constructor is always null. I thought that
`Policies.SetAllProperties(p => p.OfType<IApplicationConfigurationSection>());`
would do the trick, but it didn't.
I have found that if I discard setter injection and go with constructor injection, it works as advertised. I'd still like to know where I'm going wrong, but I'd like to stress that I'm not a StructureMap guru - there may be a better way to avoid having to constructor-inject my base class dependencies. If you know how I should be doing this but am not, please share.
While constructor injection in this scenario appears to be the better solution to the stated problem as it follows The Explicit Dependencies Principle
Methods and classes should explicitly require (typically through method parameters or constructor parameters) any collaborating objects they need in order to function correctly.
The mention of only needing to access the AppConfig in your views leads me to think that this is more of an XY problem and a cross cutting concern.
It appears that the controllers themselves have no need to use the dependency so stands to reason that there is no need to be injecting them into the controller explicitly just so that the dependency is available to the View.
Consider using an action filter that can resolve the dependency and make it available to the View via the same ViewBag as the request goes through the pipeline.
public class AccessesAppConfigAttribute : ActionFilterAttribute {
public override void OnActionExecuting(ActionExecutingContext filterContext) {
var resolver = DependencyResolver.Current;
var appConfig = (IApplicationConfigurationSection)resolver.GetService(typeof(IApplicationConfigurationSection));
filterContext.Controller.ViewBag.AppConfig = appConfig;
}
}
This now makes the required information available to the views with out tight coupling of the controllers that may have a use for it. Removing the need to inject the dependency into derived classes.
Either via adorning Controller/Action with the filter attribute
[AccessesAppConfig] //available to all its actions
public class HomeController : Controller {
//[AccessesAppConfig] //Use directly if want to isolate to single action/view
public ActionResult Index() {
//...
return View();
}
}
or globally for all requests.
public class FilterConfig {
public static void RegisterGlobalFilters(GlobalFilterCollection filters) {
filters.Add(new AccessesAppConfigAttribute());
}
}
At this point it really does not matter which IoC container is used. Once the dependency resolver has been configured, Views should have access to the required information in the ViewBag
I have the following repository classes for Redis databases:
public class RedisRepositoryBase<TRedisEntity> : IRedisRepository<TRedisEntity> where TRedisEntity : class, IRedisEntity
public class MyClassARepository : RedisRepositoryBase<MyClassA>
public class MyClassBRepository : RedisRepositoryBase<MyClassB>
public class MyClassCRepository : RedisRepositoryBase<MyClassC>
TRedisEntity is the base class of my POCOs where some common props like Id, CreationDate and others are defined. The constructor of the derived repo classes is defined as such:
public MyClassARepository(IRedisClientsManager redisManager) : base(redisManager)
{
}
Now I try to register those repositories in my AppHost class:
public override void Configure(Container container)
{
container.Register<IRedisClientsManager>(c => new PooledRedisClientManager(connStr)); // the connection pool
// Now I do not understand how to register the repositories
container.Register<IRedisRepository<IRedisEntity>>(c => new MyClassARepository(c.Resolve<IRedisClientsManager>()); //This is wrong, get conversion error!
// ... other configuration stuff
}
Reading the ServiceStack IOC docs, I see there are many ways to register my repos but I cannot get it going....
I guess I have to register all my derived classes or is this a wrong assumption?
What is the correct syntax to register my repo classes with Func?
Many thanks!
Your MyClassARepository only implements IRedisRepository<MyClassA> so you can only do:
container.Register<IRedisRepository<MyClassA>>(c =>
new MyClassARepository(c.Resolve<IRedisClientsManager>());
If I have a base class for my services like
public abstract class BaseService<T,R> : ServiceStack.ServiceInterface.Service
{
public R Get(T request)
{
}
}
Then service stack crashes with
An attempt was made to load a program with an incorrect format.
I think Servicestack should ignore the abstract generic classes when registering services. Is there any way to tell servicestack to ignore some service classes ?
By default, ServiceStack is including all types in the assemblies as candidates for services. It gets that exception when it tries to instantiate the class.
By overriding the CreateServiceManager in the host class, you can inject your own filtering of types so that abstract and unclosed generics are excluded.
protected override ServiceManager CreateServiceManager(params Assembly[] assembliesWithServices)
{
return new ServiceManager(
new Container(),
new ServiceController(
() =>
assembliesWithServices.SelectMany(
assembly => assembly.GetTypes().Where(t => !t.IsAbstract && !t.IsGenericTypeDefinition))));
}
I have this interface for using AutoMapper:
public interface IMapper
{
object Map(object source, Type sourceType, Type destinationType);
}
Then for each type of data, I have a different mapper class , for example:
public class UserMapper : IMapper
{
static UserMapper()
{
Mapper.CreateMap<User, UserViewModel>();
Mapper.CreateMap<UserViewModel, User>();
}
public object Map(object source, Type sourceType, Type destinationType)
{
return Mapper.Map(source, sourceType, destinationType);
}
}
Then I have IMapper as one of the parametter in my controller class like this:
public UsersController(IUsersRepository repo, IMapper userMapper)
{....}
I am using Windsor as the IOC for my application and the problem is that I want to register the components, so that when running in UsersController , it use the UserMapper class and if running on ProductsController it will use my ProductMapper class.
My registration code looks something along the line of this:
container.Register(
Component.For<IMapper>()
.ImplementedBy<UsersMapper>()
.Named("usersMapper"),
Component.For<IMapper>()
.ImplementedBy<ProductsMapper>()
.Named("productsMapper"),
Component.For<ProductController>()
.ServiceOverrides(ServiceOverride.ForKey("usersMapper").Eq("productsMapper"))
)
I have done my homework on google and stackoverflow, and i know that I need to use ServicesOverride but I am still stuck on this, could anyone give me a hand please?
Thanks
While svick's solution looks correct to me (I haven't attempted to compile it, though), this scenario is an excellent case for convention-based configuration.
Let's introduce this convention: Each consumer of IMapper will signal the intended role of the mapper by its name. By default, that name will be matched with a type of the same name - only with different casing.
So, constructor parameters could be mapped like this:
userMapper -> UserMapper
productMapper -> ProductMapper
In Castle Windsor, such a configuration might look like this:
container.Register(Classes
.FromThisAssembly()
.Pick()
.WithServiceAllInterfaces()
.WithServiceSelf());
container.Kernel.Resolver.AddSubResolver(
new MapperConvention(container.Kernel));
And the Sub Resolver (where the magic really happens) looks like this:
public class MapperConvention : ISubDependencyResolver
{
private readonly IKernel kernel;
public MapperConvention(IKernel kernel)
{
this.kernel = kernel;
}
public bool CanResolve(CreationContext context,
ISubDependencyResolver contextHandlerResolver,
ComponentModel model,
DependencyModel dependency)
{
return typeof(IMapper).IsAssignableFrom(dependency.TargetType);
}
public object Resolve(CreationContext context,
ISubDependencyResolver contextHandlerResolver,
ComponentModel model,
DependencyModel dependency)
{
var representativeMapperType = typeof(UserMapper);
var concreteMapperType = representativeMapperType.Assembly
.GetExportedTypes()
.Where(t =>
t.Name.Equals(dependency.DependencyKey,
StringComparison.OrdinalIgnoreCase))
.Single();
return this.kernel.Resolve(concreteMapperType);
}
}
This registration works for me:
container.Register(
Component.For<IMapper>()
.ImplementedBy<UserMapper>()
.Named("userMapper"),
Component.For<IMapper>()
.ImplementedBy<ProductMapper>()
.Named("productMapper"),
Component.For<UsersController>()
.ServiceOverrides(ServiceOverride.ForKey<IMapper>().Eq("userMapper")),
Component.For<ProductsController>()
.ServiceOverrides(ServiceOverride.ForKey<IMapper>().Eq("productMapper"))
);