search

MightyOrm / Mighty

A new, small, dynamic micro-ORM. Highly compatible with Massive, but with many essential new features.
BSD 3-Clause "New" or "Revised" License
101 stars 20 forks source link

Consider renaming MightyORM base class #1

Closed brgrz closed 5 years ago

brgrz commented 5 years ago

Consider renaming MightyORM base class to something more along the lines of dynamic model / dynamic entity.

First, MightyORM name does not follow C# naming guidelines (should be MightyOrm). Second, when doing "new MightyORM()" I feel like I'm creating new UoW/context instance (which of course we are not because this isn't UoW).

Massive had DynamicModel and it expressed exactly what it represented.

mikebeaton commented 5 years ago

Thank you for your interest in the project, @brgrz (Marko)!

You are right about the .NET naming conventions. Mostly I find them useful. In this one case I find them overly restrictive. MySQL is not really MySql, SQL Server is not really SqlServer, and MightyORM is not a Mighty Orm (what is an Orm? ;) ). It seems to me more self-documenting if the user gets to create an ORM (we know what that is) and not an Orm (again, what dat?)! But maybe I should shift on this. I suspect that if I don't, it will keep coming back to haunt me!

As regards DynamicModel: this really always was one of the few bits of Massive naming that I didn't like. I suspect that depends strongly on how you use Massive (or perhaps now Mighty?) though. Because being a dynamic model (of a certain table) was always only one of the things that Massive did well. You could always create a connection to a DB without specifying a table, and then do lots of useful ad hoc querying through it. This is perhaps particularly relevant if you were using Massive to call stored procedures (which you always could, but only to a rather limited extent), and is even more so in Mighty, which has much, much more complete stored procedure support, including parameters names and directions, etc. (and even Cursor output parameter support on the two databases where this makes sense, namely Oracle and PostgrSQL). So, basically, Massive now has a ton of stuff that I think you might usefully want to do without specifying a table name (all whilst still fully and compatibly supporting all the table-specific - and non-table-specific - things that Massive could previously do).

Which is why I prefer (let's say) MightyOrm!

mikebeaton commented 5 years ago

Marko,

Let me know if you're still badly unconvinced by this? (As I'm probably planning to close it.)

As an update, my naming is based on the fact that MightyOrm is an Object-Relational-db Mapping class.

If you give it a table name (explicitly or implicitly via the class name of a child class) then many (but still far from all) of the things it can do are related to it working as a (dynamic) model of that table. But even if you don't provide a table name, you can do lots useful database access with the class anyway.

Since Mighty now supports generics (i.e. strongly typed as well as dynamic row values) then this also makes the name DynamicModel seem less appropriate - for all that several of the features of Mighty, following Massive, strongly leverage C# dynamic anyway, and in general work in an on-the-fly (so, loosely, 'dynamic') way.

Mike

brgrz commented 5 years ago

I guess that makes sense.