Доступ к автомату из другой библиотеки классов в ядре .net - PullRequest
Новая
       10

Доступ к автомату из другой библиотеки классов в ядре .net

0 голосов
/ 28 сентября 2018

Я использую ядро ​​asp.net 2.0.В моем решении есть проект DataAccess и проект службы API 20.И это число увеличивается с каждым днем.Я буду использовать AutoMapper.Но я не хочу добавлять автоматы из NuGet для всех проектов.Итак, я хочу добавить к единственному решению DataAccess и добавить профили в решение DataAccess.И я хочу позвонить из проекта API, написав "mapper.Map (originalObject)".Мы можем добавить Automapper в проект API, добавив startup.cs.Но мой проект DataAccess - это библиотека классов.Так что у него нет startup.cs.Как я могу это сделать и могу ли я получить доступ к Autopper из сервисных проектов?(Я не хочу добавлять автоматы из NuGet в API)

1 Ответ

0 голосов
/ 28 сентября 2018

Может быть много решений этой проблемы, я предлагаю только два из них, и эти подходы также могут меняться в зависимости от вашего выбора и сценария.Независимо от того, знает ли ваш вспомогательный класс все типы, которые будут отображаться, или другим пользовательским библиотекам необходимо зарегистрировать свои собственные классы POCO, предпочитаете ли вы создавать преобразователь ... Вы также можете кэшировать преобразователи и возвращать его, если он запросил снова.

Вот простые примеры кода: 

class Foo
{
     public string Name { get; set; }
}

class Bar
{
    public string Name { get; set; }
}

static void Main(string[] args)
{
    //First approach usage
    Bar _bar1 = MapperHelper.MapFrom<Bar>(new Foo() { Name = "bbbbb" });

    //Second approach usage
    IMyMapper _myMapper = MapperHelper.GetMapperFor<Foo, Bar>();
    Bar _bar2 = _myMapper.MapFrom<Bar>(new Foo() { Name = "aaaAAA" });

    //Third approach usage
    Bar _bar3 = MapperHelper.Map<Bar, Foo>(new Foo() { Name = "cccc" });
}

public interface IMyMapper
{
    T MapFrom<T>(object entity);
}

class MyMapper : IMyMapper
{
      IMapper mapper;

      public MyMapper(IMapper mapper)
      {
            this.mapper = mapper;
      }

      public T MapFrom<T>(object entity)
      {
           return mapper.Map<T>(entity);
      }
}

public static class MapperHelper
{
     static IMapper staticMapper;

    static MapperHelper()
    {
         var config = new MapperConfiguration(cfg => {
         cfg.CreateMap<Foo, Bar>();
         });

        staticMapper = config.CreateMapper();
     }

     //First approach, create a mapper and use it from a static method
     public static T MapFrom<T>(object entity)
     {
           return staticMapper.Map<T>(entity);
     }

     //Second approach (if users need to use their own types which are not known by this project)
     //Create you own mapper interface ans return it
     public static IMyMapper GetMapperFor<TSource, TDestination>()
     {
            var config = new MapperConfiguration(cfg => {
                cfg.CreateMap<TSource, TDestination>();
            });

            var _mapper = config.CreateMapper();

            return new MyMapper(_mapper);
     }

     //Third sample, create and use mapper inside a static helper method
     //This is for mapping foreign types that this project does not 
     //include (e.g POCO or model types in other projects)
     public static TDestination Map<TDestination, TSource>(TSource entity)
     {
         var config = new MapperConfiguration(cfg => {
               cfg.CreateMap<TSource, TDestination>();
            });

            var _mapper = config.CreateMapper();

            return _mapper.Map<TDestination>(entity);
     }
 }

Сначала создается конфигурация для известных типов и используется этот преобразователь.Второй создает маппер и возвращает его в классе-оболочке.Третий создает и использует маппер для операции отображения и возвращает только сопоставленный объект.

Большинству людей не нравятся статические классы и методы, поскольку они вызывают строгие нежелательные зависимости, их нельзя легко заменить.Таким образом, создание фабричных или служебных классов, регистрация их в контейнере внедрения зависимостей и объединение их в случае необходимости является предпочтительным.

...