Fortis vs Glass.Mapper (part 3)

I know, I am being annoying about this, but today I’m gonna share more tests. In order to keep this constructive I will attach code that I have been using for my measurements.

So I created a solution which you can find here It uses same sitecore instance and both Glass and Fortis were installed there. There is a /testrunner.aspx page which runst tests and drows charts with test results.

As I described in my first post, Glass behaves different way when mapping Sitecore items using interfaces and mapping using classes that implement these interfaces. In case of using TDS and code generation templates we have both interfaces and types generated into the model. Let’s see what is the difference performance-wise in both cases.

In previous post I shared chart which shows performance test results using interface mappings. Basically next chart that I got from my new page shows pretty much same results:


The code for Glass part here is using interfaces when accessing SitecoreService methods like:

var item = SitecoreService.GetItem<INavigation>(contentPageId);
var typedItem = item.GlassCast<INavigation>();

Lets see same test cases but replace interface to concrete types for Glass code. So methods above will be executed as:

var item = SitecoreService.GetItem<Navigation>(contentPageId);
var typedItem = item.GlassCast<Navigation>();


Well, test results have remarkably changed.

As you can see the Read / Render field cases for Glass now work super fast. But in the same time, the “Get Item” and “Expose From Item” gone a bit crazy. I believe when using types instead of interfaces, the object is being exposed the moment when we getting it from the method with all field values (which is a bit strange), so reading fields turns out to be just reading the object properties. Well, to read the field we still need to execute the slow “Get Item” method so I don’t think we win here.

Probaby that’s it what I wanted to show today.

Now we have the project on github with both Fortis and Glass in it. Apparantly we can play a bit more with Fortis and Glass comparison in terms of building same features using both frameworks.

3 thoughts on “Fortis vs Glass.Mapper (part 3)

  1. Can Fortis cache objects? Did you take that into consideration when making these tests? Does Fortis have Edit Frames? Glass Mapper v4 has significant performance improvements, introduces caching and adds other useful features. And stating that you don’t care about community is simply silly my friend. Then you shouldn’t be a web developer.


  2. Thank you for such a constructive reply “my friend” 🙂 The thing is that Fortis does not need to cache anything as long as Sitecore already has decent number of cache layers and Fortis is just a wrapper around the API. There is a cache for the template-to-interface map though which is obvious.

    I did not test it with the latest Glass version but I did enable the cache. The fact that it needs to cache objects simply tells that there is something wrong and something slow. New cache layers introduce new limitations and possible rooms for defects.

    Although, you are welcome to compare the new version and show who is “the web developer” lol :). Otherwise you just sound too religious about something that is simple and convenient for you and showing that you have no willing to learn something new. You are welcome to write me to my mail if you have any thoughts or let’s have a beer some time 🙂


  3. Caching of objects is useful where you can’t use Sitecore cache, for example WFFM.

    Nothing about the religion… 😉 But good thoughts, I might give Fortis a try, but for now Glass just has the features I need, while productivity developing them from scratch using Fortis would decrease quite a bit.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s