I want to place Automapper profile in my Business Layer - asp.net-core

I've created a web api core 2.0 application.
I've got my main app and the Business Layer.
I want to place the automapper profile in the business layer so that all the mappings are made in the business layer. My business layer is just a class library project.
Is this possible? or do I need to place all my mapping in a Profile class in the main app?
Just a theoretical explanation can help.

Yes, it's possible but it depends on where the model classes reside.
You can give each layer or project a Profile where you map the appropriate model classes. Then in the project where you want to use the mapper, create the ObjectMapper class to load the Profiles.
namespace BL.Config
{
public class MapperProfile : Profile
{
public MapperProfile()
{
CreateMap<Entity, Dto>();
...
}
}
public class ObjectMapper
{
public static IMapper Mapper
{
get { return mapper.Value; }
}
public static IConfigurationProvider Configuration
{
get { return config.Value; }
}
public static Lazy<IMapper> mapper = new Lazy<IMapper>(() =>
{
var mapper = new Mapper(Configuration);
return mapper;
});
public static Lazy<IConfigurationProvider> config = new Lazy<IConfigurationProvider>(() =>
{
var config = new MapperConfiguration(cfg =>
{
cfg.AddProfile<BL.Config.MapperProfile>();
cfg.AddProfile<AppCore.Config.MapperProfile>(); // any other profiles you need to use
});
return config;
});
}
}
When I need to use AutoMapper, I use the ObjectMapper.Mapper to get my mapper instance. I like to add this to an abstract service.
public interface IAutoMapperService
{
IMapper Mapper { get; }
}
public abstract class AutoMapperService : IAutoMapperService
{
public IMapper Mapper
{
get { return BAL.Config.ObjectMapper.Mapper; }
}
}
And usage: The service has the Mapper member.
public class SomeService : AutoMapperService, ISomeService
{
public Foo GetFoo()
{
var foo = Mapper.Map<Foo>(bar);
return foo;
}
}
Or just implement the IAutoMapperService if you can't inherit another base class.
The downside is BL requires the AutoMapper dependency. But using this way I find I can hide many models from the other layers.

Related

Define class dynamically with Service Locator - Asp.Net Core

I am working with Asp.Net Core application. I have two classes namely Online and Offline. I have created interface and defined the methods in these two classes. Based on the need I have to connect to anyone of these two classes.
Previously when I worked in Asp.Net MVC, I have used unity container and Service Locator to specify the class name in XML file for invoking the class dynamically (between online and offline).
Now I want to implement the same with Asp.Net core. But I am not sure how to specify the class name outside for method invocation. Kindly help.
Thanks
In .net core dependency injection is in built. You don't need unity or any other any more.
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-5.0
You can achieve what you want by using a little tweak.
//// classes
public interface IFileUploadContentProcess
{
IEnumerable<StoreOrder> ProcessUploads(IFormFile file);
}
public class ProcessExcelFiles : IFileUploadContentProcess
{
public IEnumerable<StoreOrder> ProcessUploads(IFormFile file)
{
throw new NotImplementedException();
}
}
public class ProcessCsvFiles : IFileUploadContentProcess
{
public IEnumerable<StoreOrder> ProcessUploads(IFormFile file)
{
throw new NotImplementedException();
}
}
//// register it
public void ConfigureServices(IServiceCollection services)
{
services.AddControllers();
services.AddTransient<IStoreOrderService, StoreOrderService>();
services.AddTransient<ProcessExcelFiles>();
services.AddTransient<ProcessCsvFiles>();
// Add resolvers for different sources here
services.AddTransient<Func<string, IFileUploadContentProcess>>(serviceProvider => key =>
{
return key switch
{
"xlsx" => serviceProvider.GetService<ProcessExcelFiles>(),
_ => serviceProvider.GetService<ProcessCsvFiles>(),
};
});
}
//use it
public class StoreOrderService : IStoreOrderService
{
private readonly Func<string, IFileUploadContentProcess> _fileUploadContentProcess;
public StoreOrderService(Func<string, IFileUploadContentProcess> fileUploadContentProcess)
{
_fileUploadContentProcess = fileUploadContentProcess;
}
public async Task<IEnumerable<StoreOrder>> UploadStoreOrdersAsync(IFormFile file)
{
//// passing csv to process csv type(default), if xlsx, pass xlsx
var records = _fileUploadContentProcess("csv").ProcessUploads(file);
return records;
}
}
After lot of brainstroming, I found the below solution
Create a class for ServiceLocator
public class ServiceLocator
{
private ServiceProvider _currentServiceProvider;
private static ServiceProvider _serviceProvider;
public ServiceLocator(ServiceProvider currentServiceProvider)
{
_currentServiceProvider = currentServiceProvider;
}
public static ServiceLocator Current
{
get
{
return new ServiceLocator(_serviceProvider);
}
}
public static void SetLocatorProvider(ServiceProvider serviceProvider)
{
_serviceProvider = serviceProvider;
}
public object GetInstance(Type serviceType)
{
return _currentServiceProvider.GetService(serviceType);
}
public TService GetInstance<TService>()
{
return _currentServiceProvider.GetService<TService>();
}
}
Step 2: Create interface and inherit in the classes and define the interface methods
Step 3: Define class name in appSettings.json and read the values in startup.cs
public void ConfigureServices(IServiceCollection services)
{
//reading from appSettings.json
string strClassName = Configuration["DependencyInjection:className"];
if (strClassName == "OnlineData")
services.AddTransient<<<InterfaceName>>, <<OnlineClassName>>>();
if (strClassName == "OfflineData")
services.AddTransient<<<InterfaceName>>, <<OfflineClassName>>>();
}
Step 4: Create object for the dynamic class inside controller/action method
InterfaceNamemyService = ServiceLocator.Current.GetInstance<>();

Nhibernate and decapsulating decorators

I am currently working on a project with NHibernate that requires security and auditing aspects. Those two seem to be perfect fits for the decorator pattern. Therefore my first step was to extract an interface for the entities to be decorated. Next, I decorated the relevant repositories to return decorated entities that implement the required auditing and security respectively. This works as expected.
However, a problem arises when NHibernate is asked to save a decorator instead of the base entity. Consider the following model as a simple example. It consists of an Engine that can be composed from multiple components.
public interface IEngine {
void AddComponent(IComponent component);
// Other Engine methods
}
public interface IComponent {
// Component methods
}
// Component basic entity mapped via NHibernate
public class Component : IComponent {
}
// Engine basic entity mapped via NHibernate
public class Engine {
private IList<IComponent> _components;
public Engine(IEnumerable<IComponent> components) {
_components = components.ToList();
}
public void AddComponent(IComponent component) {
_components.Add(component);
}
// Other engine methods
}
// Component security decorator
public class SecurityComponent : IComponent {
private readonly IComponent _innerComponent;
public SecurityComponent(IComponent innerComponent) {
_innerComponent = innerComponent;
}
// delegated and changed methods
}
// Engine security decorator
public class SecurityEngine {
private readonly IEngine _innerEngine;
public SecurityEngine(IEngine innerEngine) {
_innerEngine = innerEngine;
}
// delegated and changed methods
}
The code that is responsible for creating and saving Engines does not know anything about security decorators:
var components = componentRepository.RetrieveMatchingComponents(); // because the repository is decorated, this method returns SecurityComponents
var engine = new Engine(components);
engineRepository.Create(engine); // will fail because NHibernate cannot deal with the decorators referenced in the Engine
The only solution I can currently think of is to move the object creation into a factory that can also be decorated by the security code. The security factory would
need to decapsulate the SecurityComponents in order to construct a inner engine consisting only of basic entities. In addition the SecurityEngine would need to
decapsulate all incoming SecurityComponents. Finally the SecurityEngineRepository would need to decapsulate incoming SecurityEngines so that the innermost repository
that calls Session.Save receives only a basic entity Engine consisting only of basic entity Components. For example:
public class SecurityComponent : IComponent {
private readonly IComponent _innerComponent;
public SecurityComponent(IComponent innerComponent) {
_innerComponent = innerComponent;
}
public IComponent Decapsulate() { return _innerComponent; }
// delegated and changed methods
}
public class SecurityEngine {
private readonly IEngine _innerEngine;
public SecurityEngine(IEngine innerEngine) {
_innerEngine = innerEngine;
}
public void AddComponent(IComponent component) {
// do security stuff (e.g check if adding components is allowed)
IComponent result;
if (component is SecurityComponent) {
result = ((SecurityComponent)component).Decapsulate();
} else {
result = component;
}
_components.Add(result);
}
// other delegated and changed methods
}
public interface IEngineFactory {
IEngine CreateEngine(IEnumerable<IComponent> components);
}
public class EngineFactory : IEngineFactory {
public IEngine CreateEngine(IEnumerable<IComponent> components) { return new Engine(components); }
}
public class SecurityEngineFactory : IEngineFactory {
// decorator constructor
public IEngine CreateEngine(IEnumerable<IComponent> components) {
// decapsulate security components
var innerEngine = _innerEngineFactory.CreateEngine(decapsulatedComponents);
return new SecurityEngine(innerEngine);
}
}
The engine construction code:
var components = componentRepository.RetrieveMatchingComponents(); // because the repository is decorated, this method returns SecurityComponents
var engine = engineFactory.CreateEngine(components); // SecurityEngineFactory will return a SecurityEngine with a well formed inner Engine
engineRepository.Create(engine); // SecurityEngineRepository will decapsulate the SecurityEngine
This solution seems like a code smell to me. Is there a general pattern to solve this problem? Any suggestions on how to improve this solution?

Castle windsor wire generic irepository with 2 types

Hi I am trying to change a code example found here
http://imar.spaanjaars.com/577/aspnet-n-layered-applications-implementing-a-repository-using-ef-code-first-part-5
In his example he uses structure map, when I converted it to windsor I can get it to work with the one repository using the following.
container.Register(Component.For<IUnitOfWorkFactory>().ImplementedBy<EFUnitOfWorkFactory>(),
Component.For<IUnitOfWork>().ImplementedBy<EFUnitOfWork>(),
Component.For<Model.Repositories.IPeopleRepository>().ImplementedBy<PeopleRepository>().LifestyleTransient());
But what I really want to do is to map all the irepository based interfacees to thier implementation.
Here is the IRepository, T is the entity, K is the prmiary key type
public interface IRepository<T, K> where T : class
{
}
Its implementation Is
public abstract class Repository<T> : IRepository<T, int>, IDisposable where T : DomainEntity<int>
{
}
My controller has the interface IPeopleRepository as a constructor paramerter.
public interface IPeopleRepository : IRepository<Person, int>
{
}
public class PeopleRepository : Repository<Person>, IPeopleRepository
{
}
I want to have one register to register all repositories, something like this, but it wont match and i get the error Service 'Spaanjaars.ContactManager45.Model.Repositories.IPeopleRepository' which was not registered
container.Register(Component.For(typeof(IRepository<,>))
.ImplementedBy(typeof(Repository<>))
.LifestylePerWebRequest());
What am i missing in regards to this? is it because my irepository has 2 generic types?
In order to map all the IRepository based interfaces to their implementations .WithService.AllInterfaces() should be used.
This registration should solve your issue.
container.Register(
Classes.FromThisAssembly()
.BasedOn(typeof(IRepository<,>))
.WithService.AllInterfaces()
.LifestylePerWebRequest());
There are some tests to test it. I claim they are green.
[TestClass]
public class InstallerTest
{
private IWindsorContainer container;
[TestInitialize]
public void Init()
{
container = new WindsorContainer().Install(new Installer());
}
[TestMethod]
public void ResilveTest_ResolvesViaIRepository()
{
// act
var repository = container.Resolve<IRepository<Person, int>>();
// assert
repository.Should().BeOfType<PeopleRepository>();
}
[TestMethod]
public void ResilveTest_ResolvesViaIPeopleRepository()
{
// act
var repository = container.Resolve<IPeopleRepository>();
// assert
repository.Should().BeOfType<PeopleRepository>();
}
}
public class Installer : IWindsorInstaller
{
public void Install(IWindsorContainer container, IConfigurationStore store)
{
container.Register(
Classes.FromThisAssembly()
.BasedOn(typeof(IRepository<,>))
.WithService.AllInterfaces()
.LifestylePerThread());
}
}

AutoMapper testing and dependency injection for resolvers

Im writing a test for an automapper map. One of the destination members in the map requires a value resolver, and that value resolver has service dependencies which are injected. I want to use the real implementation for the resolver (since thats part of the map im testing) but Id like to use mocks for the dependencies the resolver has.
Ofcourse I want to try to avoid using an ioc container for in my tests, but how do I easily resolve my value resolver's dependencies without one?
This is my rather simplified example, in the real case there are several resolvers with sometimes many dependencies, and I really dont like to basically implement my own dependency resolver in my tests. Should I use a lightweight ioc container?
[TestFixture]
public class MapperTest
{
private IMyService myService;
[SetUp]
public void Setup()
{
Mapper.Initialize(config =>
{
config.ConstructServicesUsing(Resolve);
config.AddProfile<MyProfile>();
});
}
public T Resolve<T>()
{
return (T) Resolve(typeof (T));
}
public object Resolve(Type type)
{
if (type == typeof(MyValueResolver))
return new MyValueResolver(Resolve<IMyService>());
if (type == typeof(IMyService))
return myService;
Assert.Fail("Can not resolve type " + type.AssemblyQualifiedName);
return null;
}
[Test]
public void ShouldConfigureCorrectly()
{
Mapper.AssertConfigurationIsValid();
}
[Test]
public void ShouldMapStuff()
{
var source = new Source() {...};
var child = new Child();
myService = MockRepository.GenerateMock<IMyService>();
myService .Stub(x => x.DoServiceStuff(source)).Return(child);
var result = Mapper.Map<ISource, Destination>(source);
result.Should().Not.Be.Null();
result.Child.Should().Be.SameInstanceAs(child);
}
}
public class MyProfile : Profile
{
protected override void Configure()
{
base.Configure();
CreateMap<ISource, Destination>()
.ForMember(m => m.Child, c => c.ResolveUsing<MyResolver>());
}
}
public class MyResolver: ValueResolver<ISource, Destination>
{
private readonly IMyService _myService;
public MyResolver(IMyService myService)
{
_myService = myService;
}
protected override Child ResolveCore(ISource source)
{
return _myService.DoServiceStuff(source);
}
}
}
Here's one solution, but basically its what iv done already:
http://groups.google.com/group/automapper-users/browse_thread/thread/aea8bbe32b1f590a/f3185d30322d8109
The suggestion is to use a service locator which are set up differently depending on test or real implementation.

Avoiding Service Locator with AutoFac 2

I'm building an application which uses AutoFac 2 for DI. I've been reading that using a static IoCHelper (Service Locator) should be avoided.
IoCHelper.cs
public static class IoCHelper
{
private static AutofacDependencyResolver _resolver;
public static void InitializeWith(AutofacDependencyResolver resolver)
{
_resolver = resolver;
}
public static T Resolve<T>()
{
return _resolver.Resolve<T>();
}
}
From answers to a previous question, I found a way to help reduce the need for using my IoCHelper in my UnitOfWork through the use of Auto-generated Factories. Continuing down this path, I'm curious if I can completely eliminate my IoCHelper.
Here is the scenario:
I have a static Settings class that serves as a wrapper around my configuration implementation. Since the Settings class is a dependency to a majority of my other classes, the wrapper keeps me from having to inject the settings class all over my application.
Settings.cs
public static class Settings
{
public static IAppSettings AppSettings
{
get
{
return IoCHelper.Resolve<IAppSettings>();
}
}
}
public interface IAppSettings
{
string Setting1 { get; }
string Setting2 { get; }
}
public class AppSettings : IAppSettings
{
public string Setting1
{
get
{
return GetSettings().AppSettings["setting1"];
}
}
public string Setting2
{
get
{
return GetSettings().AppSettings["setting2"];
}
}
protected static IConfigurationSettings GetSettings()
{
return IoCHelper.Resolve<IConfigurationSettings>();
}
}
Is there a way to handle this without using a service locator and without having to resort to injecting AppSettings into each and every class? Listed below are the 3 areas in which I keep leaning on ServiceLocator instead of constructor injection:
AppSettings
Logging
Caching
I would rather inject IAppSettings into every class that needs it just to keep them clean from the hidden dependency on Settings. Question is, do you really need to sprinkle that dependency into each and every class?
If you really want to go with a static Settings class I would at least try to make it test-friendly/fakeable. Consider this:
public static class Settings
{
public static Func<IAppSettings> AppSettings { get; set; }
}
And where you build your container:
var builder = new ContainerBuilder();
...
var container = builder.Build();
Settings.AppSettings = () => container.Resolve<IAppSettings>();
This would allow to swap out with fakes during test:
Settings.AppSettings = () => new Mock<IAppSettings>().Object;
Now the AppSettings class (which I assume there is only one of) you could do with regular constructor injection. I assume also that you really want to do a resolve on each call to your settings properties, thus injecting a factory delegate that retrieves an instance when needed. If this is not needed you should of course inject the IConfigurationSettings service directly.
public class AppSettings : IAppSettings
{
private readonly Func<IConfigurationSettings> _configurationSettings;
public AppSettings(Func<IConfigurationSettings> configurationSettings)
{
_configurationSettings = configurationSettings;
}
public string Setting1
{
get
{
return _configurationSettings().AppSettings["setting1"];
}
}
public string Setting2
{
get
{
return _configurationSettings().AppSettings["setting2"];
}
}
}