![]() No "secret" tables for mapping many-to-many relationships. Your data types (POCOs) are expressed clearly. You get fully type-checked access to your underlying database, with a 1-to-1 relationship between your types and the data they represent. These extensions usually go only so far as to prevent the user from having to manually manage SQL strings, which is an obvious maintenance nightmare.Īt this point of abstraction, no real complaints can be made. Micro ORMS are usually just extensions on top of raw ADO types ( IDbCommand, IDbConnection, etc) and OrmLite is no exception. However, there is a huge swath of issues that can be completely avoided by just choosing not to expose yourself. You can't escape the issues of just "getting data in and out" and the underlying database. It is often overlooked, and when it does eventually tax your solution, it can go unnoticed/unrealized. When it comes to the scope of your dependency and the exposure it brings to your project, I wouldn't take this point lightly. You'll find that the issues in OrmLite are generally about the problem-domain (getting data in-and-out of the database) or the underlying ADO provider, whereas the issues in EF generally involve the layers/types that are involved in the abstractions. You can get a sense of this by spending a few minutes on the issue pages for each ORM ( here and here). As you sit on top of more layers of abstraction and indirection, the problems that you begin to run into begin to get more cryptic and harder to isolate/fix. ![]() As the saying goes "more money, more problems", right? As you increase your surface area (including your dependency graph), you increase your chances of running into bugs/issues. Purely considering lines-of-code can be a fool's errand, but there is more to the story here. Using cloc, here is the overview of the size of each codebase. One way to do this is to consider the size of the dependency via the lines-of-code. NOTE: OrmLite is free for open-source, but paid for closed-source.Īs with picking any dependency on your project, you must step back and take a 20,000-foot view of things to determine its impact on your solution. Micro ORM - ServiceStack.OrmLite - For the sake of argument, I could easily have chosen other solutions, such as Dapper or PetaPoco, but I'm a fan of the API/features that ServiceStack.OrmLite provides.It is front-and-center in most of the "Getting Started" docs and is what most junior devs will choose when beginning their journey into. Full ORM - Entity Framework Core - Chosen because it is the unofficial official version for.NET world, but I think my point could be made when picking one of each a fully-fledged ORM, and a micro ORM. Looking back, I regret having to learn the hard way that EF is very taxing and it just isn't a good choice for most solutions. It was my preferred solution for a while and I've gotten pretty good with it. NET 3.5 days, both code-first and database-first) as well as the latest. Public int IgnoredProperty ) Īssert.Equal("Sams Post1", post.I've worked with Entity Framework (since the. It provides 3 helpers: Execute a query and map the results to a strongly typed List public static IEnumerable Query(this IDbConnection cnn, string sql, object param = null, SqlTransaction transaction = null, bool buffered = true) Located at /Dapper Packagesĭapper is a NuGet library that you can add in to your project that will extend your IDbConnection interface.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |