For example, the whole PetaPoco framework takes just a single file with around 4000 lines, where most of the lines are comments. As a result of such simplicity file size of Micro ORM is very small, and when the developer needs to look at how micro ORM works it’s very easy for him to do it and does not require a lot of effort. What Micro ORM is doing is they provide only features that should exist to make it work, usually, it’s read from database feature and mapping feature. But all this complexity has hurt the performance of ORM as well as makes it much more difficult to understand and learn for new developers. But usually, when we using these tools we use just a small subset of the ORM framework, in most cases, we even don’t know what is most of the features of the big ORMs. If we take any of the existing ORM tools, we will find hundreds of features, which developers of these ORMs are developed during years of their existence. In fact, there are only two benefits of Micro ORM comparing to ORM, the first is simplicity and the second is a great performance. It’s not a huge limitation, but have another tool to keep track of changes to your database will require additional efforts, FluentMigrator doing this job pretty well if you need such a tool. Migration: most of ORM tools support some kind of migration or code first approach, where you design your model and after executing application database objects created based on the model, and when you make changes database updates as well, this feature is not supported by Micro ORM, you have to use 3rd party tools to do a migration.In fact, it’s not a big limitation at all, for example, NHibernate does not have a designer as well (at least a free designer), but it’s extremely easy to set up your model and mapping. No designer: most existing ORM usually have nice designer, where you can create your model, set relationship between objects (a good example Entity Framework), micro ORM does not support it, you should code all your models and relationship.For me, this was one of the reasons switching from Micro ORM tools This limitation is very annoying, you can still load parent/child object, but you have to construct your SQL query special way or do multiple queries, also when saving parent, you should not forget about children. Relationships: there is no one-to-one, many-to-many relationship supported, which means, when you load an object from the database, all related objects will not be automatically loaded or saved, if you want to load related objects, you have to construct your query special way.Frankly speaking, it’s not a huge limitation and it’s very easy to solve it just applying. Caching: Second Level Cache is not supported, so if you need it, you have to implement some kind of database caching yourself.Below you can see the most important limitations of Micro Orm: What are the limitations of Micro ORM?įrom my experience, you can live with some limitations for micro ORM, but some can stop you from using it in favour of full-featured ORM tools. It means that MicroORM suppose to do the same job of mapping table to object, but it sacrifices a number of features to have a better performance. You probably already know what is the Micro ORM, but if not: Micro ORM is a lightweight ORM, usually limited in features, but performing faster than full-featured ORM. When talking about full-featured ORM, it’s usually Entity Framework or NHibernate. Peta Poco is similar to Dapper but makes you write less SQL because of using attributes on your model. The most popular is Dapper, from StackOverflow, it also the fasters of all existing. When talking about micro ORM it usually does not matter which one to use, the differences are usually very small. I have used Micro ORM for one of my projects recently and want to share my experience with such micro ORM as Dapper or Peta Poco, as well as compare them with such ORM tools as EntityFramework or NHibernate.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |