Wrappers vs Mappers
Glass.Mapper.Sc is different to other Sitecore Item abstractions that are available. Glass.Mapper.Sc is a mapping solution and not a wrapping solution.
So what is the difference?
In a mapping solution the data is read from the Sitecore Item and then written to the property on your model. In a wrapping solution the model property reads and writes directly to the underlying Sitecore Item. The difference is clear when you look at the code typical class.
A typical mapping model:
A typical wrapping model:
The first thing that is clear, is that there is a huge difference in the amount of code that you have to write for wrapping solutions. Typically most wrapping solutions will require some form of code generation where as a mapping solution allows you to choose between hand writing your models or using code generation.
A mapping solution also disconnects the model from the underlying item. This means that you can alter the properties on your model without affecting the underlying Sitecore Item. For example consider the following code that might be in a controller that uses a mapping solution:
Using a wrapping solution it isn't possible to write this type of logic safely because it requires putting the underlying Sitecore item into an editing state.
Pros and Cons
Let's look at the Pros and Cons of each solution.
- Models can either be classes or interfaces, you don't need both.
- Models can easily be serialised for storage, for example in session or a cache.
- Models can be hand written or code generated.
- Models are disconnected from the underlying item.
- Model properties can be altered without affecting the original Sitecore item.
- Models can be plain old C# objects without any configuration.
- Class can be mapped without requiring access to the source code.
- Both interface and class models can be unit tested.
- Models don't have to match the data structures used in Sitecore.
- Mapped models are slower than wrapped models.
- It can be harder to move from the Sitecore API to the mapping API.
- The server performs more work to create the initial mapping model.
- Quicker to instantiate models.
- Can use an active record pattern.
- Typically easier to move between the Sitecore API and framework API.
- Models normally have to be code generated, they require too much code to be hand written.
- Models are normally tightly coupled to the data structure in Sitecore.
- Most solutions use interface and class pairs. The developer writes their code using the interface and the concrete model is injected at runtime.
- Models are tightly coupled to the Sitecore template. Certain solutions require a 1 to 1 mapping making these frameworks very inflexible.
- The business logic is written using the interface for the model which requires more work when mocking in a unit test.
- Configuration for the model is tightly coupled to the model.
- Access to the source code for the models is required.