Adding Dapper.Contrib Attributes to model carries dependency with Dapper library (and dapper.Contrib)

[cmarrades]

Hi,

I have been using dapper and dapper.contrib for years. Common use case is you have a project with your POCs. i.e. WhateverCompany.Model. Usual scenario is you expose "some" of this objects to the outside world, i.e. "Products" in the form of a package, so some contracts will carry the "Product" entity.

The problem comes when your customers need to add dapper dependency as it is required for attributes as "ComputedAttribute", "TableAttribute", etc. In few words, packaging the "Model" project will add "Dapper" and "Dapper.Contrib" packages which is not ideal, as you are only decorating one property with an attribute. I.e.:

[Computed] public DateTime? EffectiveDate { get; set; }

I think it would be ideal if you would package these attributes in a smaller project, so there is not a dependency with the whole Dapper project, or else use reflection in a way that would allow to import (copy) these attributes to the own project, which actually works for the "TableAttribute" but not for the rest of them.

This way the Repo project would need this Dapper dependency, but the Model project and all the referencing clients wouldn't need to add this dependency to the projects.

Thanks

[NickCraver]

Check out DapperLib/Dapper#722 for discussions on this. The attributes will ultimately be in the main Dapper package (not .Contrib) and result in 1 dependency. I don't believe relying on a single package which with all builds is still about 250KB is a big deal, especially with the way packages are headed.

However, the alternative (splitting them out) means everyone using Dapper is now dealing with more than 1 package and has to restore Dapper and this other thing. That's not very user friendly and lengthens restore/build times, etc. It's just not worth the complication or cost to users, IMO.

[cmarrades]

Hi Nick,

Thanks for your response. As I can see there is a long thread on this so I won't push it much. Just by moving them up to Dapper would remove one dependency in all of the "client" projects, which still it's not perfect, but I guess they have to be in some place. So that's good.

However, I'm not sure package size should dictate how different objects should be packaged. I.e. looks cleaner when a client has a reference to Dapper.Attributes rather than Dapper, but I agree the size it's not sthing worrying.

As I said, thanks for your response. I've been using Dapper in few companies already and with the time I got to see few bits that would make it look bit nicer, so I thought it was worthy to share the idea. Overall it's a great library.

Keep up the good work! ;)