Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider renaming MightyORM base class #1

Closed
brgrz opened this issue Oct 4, 2018 · 3 comments
Closed

Consider renaming MightyORM base class #1

brgrz opened this issue Oct 4, 2018 · 3 comments

Comments

@brgrz
Copy link

brgrz commented Oct 4, 2018

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
Copy link
Member

mikebeaton commented Oct 4, 2018

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
Copy link
Member

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
Copy link
Author

brgrz commented Apr 2, 2019

I guess that makes sense.

@brgrz brgrz closed this as completed Apr 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants