|
Linq2SQL. And yes, my experiences with EF are similar. What's worse though is that a lot of the time, an ORM isn't necessary. Take a server-side query that is converted to JSON for displaying data on the client-side browser. Why go through an ORM? Yet I see people using EF to load the query into a model, then serialize the model into JSON, then return it to the client. Why go through that extra step?
Or similarly, on a thick client, it's easy enough to data bind directly to a DataTable, even if it's only one row where you want to display the data in discrete fields rather than a grid, and you can wire up the events to track changes and persist the data for a responsive UI with little effort.
|
|
|
|
|
I agree.
But I find models useful when you need things like property change notification. They're also useful for representing a single data item. Passing a while DataTable around works but seems rather bulky to me.
Probably 6 one way, half dozen the other.
Thanks
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Right, I haven't yet encountered a database access situation that couldn't easily be dealt with by using DataReaders, DataTables, DataViews, DataRows, etc.
Microsoft even provides DataAdapters (ptui) for Bob's sake!
ORMs are definitely a solution looking for a problem.
|
|
|
|
|
But wait... it's a shiny new UI tool with cool graphics... so we NEED it.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
The reason we have ORMs now is because we can't use FPSE to connect our ASP pages to their MSAccess databases
Director of Transmogrification Services
Shinobi of Query Language
Master of Yoda Conditional
|
|
|
|
|
Were I to use one it would be one I created.
Third choice would be one from Microsoft, never from a third-party.
modified 12-Apr-18 13:25pm.
|
|
|
|
|
|
Kevin Marois wrote: I'm curious as to what ORM you use and why.
I'm curious as to why you are curious
|
|
|
|
|
Like I said, I really like Linq to Sql, but it's an older technology. Got me thinking about what ppl are using these days.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Just beginning with NHibernate, at first I was very skeptical, but now I am a bit milder. It was not my choice of course but imposed by management. Clearly this is not an ORM to use if you are in a hurry due to it's complexity ...
|
|
|
|
|
RickZeeland wrote: Clearly this is not an ORM to use if you are in a hurry due to it's complexity
Kind of contradicting the purpose, isn't it?
|
|
|
|
|
I have to agree, an ORM should make things easier for developers, but on the positive side it can make things easier once you understand how it works, a pity the learning curve is so damn steep
|
|
|
|
|
RickZeeland wrote: an ORM should make things easier for developers
RickZeeland wrote: pity the learning curve is so damn steep
|
|
|
|
|
contradictio in terminis, haha
|
|
|
|
|
Linq2SQLalso, because as you say it just works.
I also hate EF, it's a complicated POS and if you want to do anything out of the, what they obviously consider normal, you will have bend nails with your teeth to get it to work.
Everyone has a photographic memory; some just don't have film. Steven Wright
|
|
|
|
|
Yupper.
One thing I hate... We generate entities into another project in the solution, and the whole shebang is under source control.
So if you first don't check out ALL the entities in the generation location, it fails to generate with read only errors. So what we've all done is select all in Windows Explorer and make everything read-write.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
EF for CRUD. (Not by my choice though)
Everything else is homegrown.
|
|
|
|
|
|
I am currently developing my own ORM. I've already completed work on all the key components such as building the database and a (sorta) simple codebase to build applications with it. I've even written a security layer. Once I've got the workflow engine sorted out, I am going to have to find a real world problem to throw it at.
I have to thank the folks at Microsoft who built the engine for Operations Manager. After poking around under it's hood for a while, I got the idea to build this little monster. It's a software library that manages it all. With it, I managed to build a password protected file sharing website in a week.
if (Object.DividedByZero == true) { Universe.Implode(); }
|
|
|
|
|
I spy with my little eye: a new series of articles coming up
|
|
|
|
|
Ha, and get skewered some more for my abuse of the Reflection namespace, I think not. All joking aside, I don't know if any of what I am working on can be considered proprietary yet but I do like to be able to build a whole new database for a specific set of data in less than half-an-hour.
I can also write code like this to work with it:
DataObject dObj = dataAccess.Objects.GetDataObject("4e813bca-8fb0-448e-8f01-d714bd8132a3");
dObj["AnIntegerProperty"].SetValue(42);
dObj.Update(TransactionContext.Current); This code fetches a specific record from a database and then pushes an updated value complete with transaction logging.
if (Object.DividedByZero == true) { Universe.Implode(); }
|
|
|
|
|
dObj["AnIntegerProperty"].SetValue(42);
Not suggesting premature optimization, but if this SetValue ends up causing any bottlenecks you can do the following which works for properties but not fields because of how the values are set internally:
class PropertyInfoWrapper
{
private Action<object, object> _setValueDelegate;
public PropertyInfoWrapper(PropertyInfo property)
{
MethodInfo delegateHelper = typeof(PropertyInfoWrapper).GetTypeInfo()
.GetMethod(nameof(this.CreateDelegate), BindingFlags.Instance | BindingFlags.NonPublic)
.MakeGenericMethod(property.DeclaringType, property.PropertyType);
_setValueDelegate = (Action<object, object>)delegateHelper.Invoke(
this,
new object[] { property.SetMethod });
}
private Action<object, object> CreateDelegate<TObject, TProp>(MethodInfo method)
{
var del = (Action<TObject, TProp>)method.CreateDelegate(typeof(Action<TObject, TProp>));
return (object obj, object val) => { del((TObject)obj, (TProp)val); };
}
public void SetValue(object container, object value) =>
_setValueDelegate(container, value);
}
I've been debating on whether to do an article about my RegexContainer[^] project for a similar reason (where this example is from). There's a lot of dislike for reflection even when it's useful.
|
|
|
|
|
The internals aren't really all that complex. The DataObject class only contains a collection of "Properties" that validate their own values when you try to set them. The real bottlenecks are database calls so I can build a little overhead into the classes without any real loss in performance.
Jon McKee wrote: There's a lot of dislike for reflection even when it's useful. I don't get this either. With Reflection, you could, in theory, write deep learning algorithms that self-optimize their own code. I approach Reflection like I do C++ code. Since both give you enough rope to hang yourself, you must weight your options and use it when your program benefits from its use or it's absolutely necessary to reach your goal.
if (Object.DividedByZero == true) { Universe.Implode(); }
|
|
|
|
|
Good luck with this. I agree it is the best way not to depend on a library which change completely (enough) after some months
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
While the Entity Framework is great and all, the one thing that really pushed me away from it is how it never optimizes the tables. I was mentored by one of the last few people who earned their SQL Server Master's Certification and he always told me that how you structure your table can have a equal if not bigger performance impact than how you write your queries. It makes perfect sense when you think about if from a database engine point of view. What's the point of simplifying development if your data lives in performance sucking tables.
if (Object.DividedByZero == true) { Universe.Implode(); }
|
|
|
|