A TypedMapper is a helpful, extrememly lightweight type-safe wrapper class around a NetQuarry Mapper object.
You typically use a TypedMapper as a helper class in an extension. You can create a TypedMapper and attach it to the sender (IMapper) of the event or you can use the TypedMapper derivative to create a new mapper – either for the purpose of creating a new row or reading/updating an existing one. Connecting a TypedMapper via one of the constructors or TypedMapper.Attach is very inexpensive and generally a safer way to work with a mapper.
The TypedMapper is an abstract base class, which means that you have to use our generator to generate derived classes that wrap your mappers. The ONLY potential drawback to using a TypedMapper derivative vs. the Mapper as is is that you will need to update (re-generate) the classes as you make metadata changes. On the applications that we (NetQuarry) are personally managing we are putting the generation code after we save the metadata and check-in the class file. We are recomending that you keep the generated classes more or less stand-alone (e.g. in its own assembly) and without any dependencies on other code.
TypedMapper objects that have custom functionality added to them should all be placed in the Data project. This allows that functionality to be shared with other consumers. You can add TypedMapper objects anywhere in your code base and add different functions to each instance. That is not recommended.
You create a typed mapper object by deriving the class from the equivalent generated template typed mapper object. The template object gives you all the type safe declarations for fields on the mapper that are on the mapper when flavor 0 is applied to the mapper. All fields with an include flavor are not in a generated TypedMapper.
To declare a typed mapper, you derive your class from the generated class template:
public class People : Comensura.Data.Generated.people<People>
public class CompaniesTemplates : Comensura.Data.Generated.companies_templates<CompaniesTemplates>
Or, more generally:
public class TName : Application.Data.Generated.TBase<TName>
You give your typed mapper class the name almost exactly derived from the generated class name, removing any underscores and proper casing the letters for legibility. Your template object is your class. Then just treat your object like any other class and add public and private methods as appropriate.
Code in Extension or TypedMapper?
A commonly asked question is where to put your business logic. The temptation is to add business logic to Mapper extensions. Well, the basic rule of thumb is that only decision/workflow/UI logic is put in the extension and data manipulation/business logic is performed in the TypedMapper object.
Having said that, there is nothing inherently wrong with putting data manipulation code in an extension as long as it’s self contained.
If you add data manipulation code that is likely to be shared then you should probably think about putting that code as a method on the TypedMapper object. The alternative to sharing code via the TypedMapper is to share the code in the Common class, but as a static method.
So, back to the TypedMapper object. Remember a TypedMapper is just a mapper and whenever you call your TypedMapper functions, your logic is going to read and write data from the current row. Of course there are many things you can do in your functions but they all relate to some operation controlled or directed by the values in the current row.