dclucas / moo Goto Github PK

Diogo, are you planning on supporting .net core?

Suport for mappings such as:

public class SourceClass
{
public IEnumerable<SourceItemClass> Items { get; set; }
}

to

public class TargetClass
{
public IEnumerable<TargetItemClass> Items { get; set; }
}

Extend behavior of AttributeMapper and ConfigurationMapper to allow inner mappers for specific properties.

AttributeBehavior:

[Mapping(MappingDirection.From, "TargetProperty", UseMapper=true)]

Similar idea for configuration.

This way, whenever an Install-Package is made, the user will have the README right in front of their eyes.

Given the classes:
public class SampleClassA
{
public OtherClass Other { get; set }
public int OtherId { get; set; }
}

public class SampleClassB
{
public int OtherId { get; set; }
}

public class OtherClass
{
public int Id { get; set; }
}

A call to sampleObjA.Map() should map the two OtherId properties, instead of Other.Id to OtherId, as sometimes happens in the current code.

Current workaround is to create a manual mapping to override the convention.

I have a ViewModel that has a nullable int (int? Year), and I am trying to map it to a Model with the same property as an int (int Year).

Moo throws an exception in this instance. Is there any way to tell moo to map the nullable to the int?

Check which level of coverage for dynamic objects Moo already has, through TDD. If functionalities are lacking, comment the tests and add defects for each one.

Add support to add secondary mappers to a mapper, to deal with specific internal properties.

I have a source object with a DateTime? and trying to map to a similar object with DateTime? I am getting this error.

Moo.MappingException : Error mapping from MatchManagement.Data.DomainEntities.Registration.MatchesAndEvents.EventEndDate to MatchManagement.UX.Models.Admin.MatchAndEvents.MatchAndEventViewModel.EventEndDate
----> System.InvalidOperationException : Operation is not valid due to the current state of the object.

I would love to see support for handling async, like Foo.MapToAsync

Keep BaseMapper for coders who are expanding the library, but provide developers a way to inherit mapping functionality and specialize it through code.

As in:

public class CustomerMVMMapper : Mapper<Customer, CustomerMVVM)
{
    public CustomerMVMMapper()
    {
        // this guy should inherit from composite mapper and upon this constructor call already have all the mapper stack ready.
        AddMapping( /* magic mapping here */);
    }
}

Add features to help on client code unit tests. For example:

1. Add events to:

• When a property mapping is discovered;
• When an object mapping begins/ends;
• When a property is mapped;
  1. Add auxiliary methods to help determine:
• Which source and target properties have been touched by the mapper;
• Which haven't.

For the time being, this issue is a placeholder for the functionalities we can think of. Once we figure out which ones we want to implement, specific items will be created for them.

A user should be able to provide custom mapping for a given Source/Target combination by implementing a simple interface:

public class PersonPersonEditModelMappingProvider : MappingProvider<Person, PersonEditModel>
{
      public void AddMappings()
      {
            this.AddMapping()
               .From(s => s.Name + s.LastName)
               .To(t => t.FullName)
      }
}

The design needs to either have a base class that provides an AddMapping method or to provide an interface that receives a repo (or a new MappingAdder class or such) and uses it. While the interface is more easily testable, the base class enforces a segregation by source/target more easily.