Dapper can't ignore nested objects for parameter?

Question

I am beginning to use Dapper and love it so far. However as i venture further into complexity, i have ran into a big issue with it. The fact that you can pass an entire custom object as a parameter is great. However, when i add another custom object a a property, it no longer works as it tries to map the object as a SQL parameter. Is there any way to have it ignore custom objects that are properties of the main object being passed thru? Example below

public class CarMaker
{
public string Name { get; set; }
public Car Mycar { get; set; }
}

propery Name maps fine but property MyCar fails because it is a custom object. I will have to restructure my entire project if Dapper can't handle this which...well blows haha

score 2 · Answer 1 · answered Oct 14 '15 at 16:29

2

Dapper extensions has a way to create custom maps, which allows you to ignore properties:

public class MyModelMapper : ClassMapper<MyModel>
{
    public MyModelMapper()
    {
        //use a custom schema
        Schema("not_dbo_schema"); 

        //have a custom primary key
        Map(x => x.ThePrimaryKey).Key(KeyType.Assigned);

        //Use a different name property from database column
        Map(x=> x.Foo).Column("Bar");

        //Ignore this property entirely
        Map(x=> x.SecretDataMan).Ignore();

        //optional, map all other columns
        AutoMap();
    }
}

Here is a link

answered Oct 14 '15 at 16:29

Void Ray

9,849
4
33
53

I have seen lots of references to this "solution". The problem I have is how to get DapperExtensions to recognize this. I have tried to override the default behavior of DapperExtensions of making any field ending with "id" and being of type int an identity field even when it is not and ignoring the field on inserts, but DapperExtensions never calls the code. Where do you instantiate this particular code so that DapperExtensions calls it? – Timothy Dooling Nov 16 '15 at 17:09
By default, DapperExtensions will look for the a map file in the same assembly as the class it is trying to map. You can also register more assemblies by calling: SetMappingAssemblies, e.g. DapperExtensions.SetMappingAssemblies(new[] { typeof(MyCustomClassMapper).Assembly }); – Void Ray Nov 18 '15 at 21:09
I don't think it is. I just stepped through the code a while back. Also reading tests might help: https://github.com/tmsmith/Dapper-Extensions/blob/master/DapperExtensions.Test/IntegrationTests/NonCrudFixture.cs – Void Ray Nov 19 '15 at 15:04
A caveat about using SetMappingAssemblies: The use of this method overrides the use of DefaultMapper so that you must supply a tablename using Table("{tablename}") in the custom classmapper-derived class. Otherwise, the pluralized automapper function will not be called for the models involved in the SetMappingAssemblies method. – Timothy Dooling Nov 19 '15 at 18:32

Timothy Dooling · Answer 2 · 2018-10-24T17:45:23.170

There is a much simpler solution to this problem.

If the property MyCar is not in the database, and it is probably not, then simple remove the {get;set;} and the "property" becomes a field and is automatically ignored by DapperExtensions. If you are actually storing this information in a database and it is a multi-valued property that is not serialized into a JSON or similar format, I think you are probably asking for complexity that you don't want. There is no sql equivalent of the object "Car", and the properties in your model must map to something that sql recognizes.

UPDATE:

If "Car" is part of a table in your database, then you can read it into the CarMaker object using Dapper's QueryMultiple.

I use it in this fashion:

dynamic reader = dbConnection.QueryMultiple("Request_s", param: new { id = id }, commandType: CommandType.StoredProcedure);
if (reader != null)
{
    result = reader.Read<Models.Request>()[0] as Models.Request;
    result.reviews = reader.Read<Models.Review>() as IEnumerable<Models.Review>;    
}

The Request Class has a field as such:

public IEnumerable<Models.Review> reviews;

The stored procedure looks like this:

ALTER PROCEDURE [dbo].[Request_s] 
(
@id int = null
)
AS
BEGIN
    SELECT *
    FROM [biospecimen].requests as bn
    where bn.id=coalesce(@id, bn.id)
    order by bn.id desc;
    if @id is not null
    begin
        SELECT 
            *
        FROM [biospecimen].reviews as bn
        where bn.request_id = @id;
    end
END

In the first read, Dapper ignores the field reviews, and in the second read, Dapper loads the information into the field. If a null set is returned, Dapper will load the field with a null set just like it will load the parent class with null contents.

The second select statement then reads the collection needed to complete the object, and Dapper stores the output as shown.

I have been implementing this in my Repository classes in situations where a target parent class has several child classes that are being displayed at the same time.

This prevents multiple trips to the database.

You can also use this approach when the target class is a child class and you need information about the parent class it is related to.

Dapper can't ignore nested objects for parameter?

2 Answers2