What do Entity developers do in this context?
-
So I took this freelance assignment where the company sent specs to India and received something half-baked that needs numerous fixes and they went looking for somebody else after the Indians couldn't/wouldn't make the fixes. Looking over the wish list that I was given, there are two types of really stupid decisions jumping out at me. First there's outright stupid, like deciding every window should actually control three different processes based on switching hiding/showing overlapping controls, using tons of check boxes with on/off code in the events because they'd never seen a radio button, and putting control events in a library instead of subclassing controls.
Then there's what I believe is the wrong tool for the job.
They decided to go the Entity route and give every query result a partial object definition (somewhere) instead of ever using datatables or recordsets. So they've got a ton of instances where they're showing a DataGrid with additional controls (like a checkbox) that lose their binding constantly. On filter, on sort, even on scroll. This particular window in question is a who's who of stupid UI with a dose of Entity Enema.
I tried adding a "SelectedInUI" field to all of these objects, which seems like a massive kludge to me. Binding still doesn't work right (changes are fired twice, are uncancellable, and disappear seemingly at random...when they don't just crash the XAML engine). Or am I supposed to make a subclass with the added fields and, stupidly, write code to transfer fields from base to derived instances, because casting doesn't work in that direction (would probably still have binding problems)? Or should I just rip it all out and use datatables like I would've if I was writing such an application? Or do I just tell them it's impossible because the framework doesn't support it?
-
Can entity classes implement interfaces? If yes, I suggest only passing interfaces.
-
Otherwise I'd use AutoMapper to copy entity objects to/from simple DTOs.
-
Many ways to skin this cat
I personally would not go with DataTables (aka pure ADO.Net). In fact in the past decade, I have only used them when working with existing implementations that are heavily based on them.
At the same time, having the concrete Entity class being exposed all the way to the UI is almost sure to create problems.
Having interfaces on the EntityClasses is one approach I use often. Occasionally use DTO's. Sometimes encapsulation of the Entity within a "UI" (or "BL") class...
-
@error @TheCPUWizard I didn't understand how either of your answers would work. I'm leaning towards telling this client those wish list items are impossible.
-
I never really found an answer to this question. My concern with interfaces is that the route is nonsensical. Every interface has to be backed by an implementation, so you're still defining them in an Entity class that's exposed all the way to the UI. There's still the binding issue on top of that, as I doubt Entity evangelists ever use them in anything but a read-only context. As soon as you have to do anything besides straight read/write, Entity's model completely falls apart.
What I'll do is just use ADO directly. Since the application is layered incredibly stupidly, I'll just make a new set of classes and windows to do the couple of items on the list. If they don't like it, I'll suggest they take up the design issues with the Indians. Fortunately, it's not a full time job where firing me for not spinning straw into gold would be a serious hardship.
-
@Zenith
Well, UI should be bound to view models (data + UI state properties). With possible third layer between those and entities, DTOs (pure data).
Binding entities directly to UI is a bad idea.This means a lot of copying of properties back and forth, which indeed is annoying.
Oh, and datatables are awful.
-
@MrL said in What do Entity developers do in this context?:
This means a lot of copying of properties back and forth, which indeed is annoying.
Which is why "mappers" were created :)
-
@TheCPUWizard said in What do Entity developers do in this context?:
@MrL said in What do Entity developers do in this context?:
This means a lot of copying of properties back and forth, which indeed is annoying.
Which is why "mappers" were created :)
I learned the hard way to stay away from them.
-
@MrL said in What do Entity developers do in this context?:
Oh, and datatables are awful.
Why?
I like being able to just handle exactly the records that I need from a database without having to define 600 different classes and fight the UI.
-
@Zenith said in What do Entity developers do in this context?:
@MrL said in What do Entity developers do in this context?:
Oh, and datatables are awful.
Why?
Clunky and cumbersome to use.
In fact I forgot almost everything about them, which is good. I didn't forget how I hated working with them.I like being able to just handle exactly the records that I need from a database without having to define 600 different classes
Generate them from the db, together with context. You don't need to define them by hand.
and fight the UI.
I thought this was your task.
-
@MrL said in What do Entity developers do in this context?:
Clunky and cumbersome to use.
A two dimensional array with columns addressable by name is clunky?
@MrL said in What do Entity developers do in this context?:
I thought this was your task.
It wouldn't be a fight with datatables.
-
@Zenith It's pretty incredible. It took me a few hours to rebuild this window in WinForms (formally WPF) and ADO (formerly Entity) but it's been worth it as all of the binding problems have completely disappeared. Just as I predicted. Now it's just a matter of jamming all of the button logic back in. That'll probably take a few more hours. But it'll be worth it now that the code is maintainable.
Seriously, fuck Entity (and probably WPF).
-
@Zenith said in What do Entity developers do in this context?:
Now it's just a matter of jamming all of the
button logicnoodles back inFTFS
-
@MrL said in What do Entity developers do in this context?:
I learned the hard way to stay away from them.
Would like to learn more. I tend to do 90% of my data transformations with the use of Mappers.
-
@TheCPUWizard said in What do Entity developers do in this context?:
@MrL said in What do Entity developers do in this context?:
I learned the hard way to stay away from them.
Would like to learn more. I tend to do 90% of my data transformations with the use of Mappers.
Someone changes a property name in one of data classes. Everything seems fine. Two weeks later system blows up in some infrequently used module, because mapper doesn't see the change and leaves something as null.
If it blows up, filling db with nulls without anyone noticing is also a possibility, of course.
-
@MrL said in What do Entity developers do in this context?:
Someone changes a property name in one of data classes. Everything seems fine. Two weeks later system blows up in some infrequently used module, because mapper doesn't see the change and leaves something as null.
If it blows up, filling db with nulls without anyone noticing is also a possibility, of course.Mapping to view models is fine. Mapping back to the data models like that, not so much.
-
@MrL said in What do Entity developers do in this context?:
Someone changes a property name in one of data classes. Everything seems fine. Two weeks later system blows up in some infrequently used module, because mapper doesn't see the change and leaves something as null.
If it blows up, filling db with nulls without anyone noticing is also a possibility, of course.Sounds like a lack of testing. For mappers, generated tests (that are only generated and then verified by a human) should catch this type of situation.
-
@TheCPUWizard said in What do Entity developers do in this context?:
@MrL said in What do Entity developers do in this context?:
Someone changes a property name in one of data classes. Everything seems fine. Two weeks later system blows up in some infrequently used module, because mapper doesn't see the change and leaves something as null.
If it blows up, filling db with nulls without anyone noticing is also a possibility, of course.Sounds like a lack of testing. For mappers, generated tests (that are only generated and then verified by a human) should catch this type of situation.
Thing is, you use mappers for quick and easy effects. And then you have to generate and maintain tests specifically for mappers. So what's the point?
With manual data copying property name mismatch is caught at compile time.
-
@MrL While I agree with the post as literally stated, isn't manually allocating object properties the "problem" Entity is foisted upon us to "solve?"
-
@Zenith said in What do Entity developers do in this context?:
@MrL While I agree with the post as literally stated, isn't manually allocating object properties the "problem" Entity is foisted upon us to "solve?"
No, it solves problems with db interaction, generally speaking.
But, it's not an uncommon idea, shared also by me, that dragging db context bound objects around is a bad thing - they should stay in their layer. This is where DTOs come in and, possibly, mappers.
-
@TheCPUWizard said in What do Entity developers do in this context?:
Sounds like a lack of testing. For mappers, generated tests (that are only generated and then verified by a human) should catch this type of situation.
Why not just generate the mapping code in the first place, then?
-
@Unperverted-Vixen said in What do Entity developers do in this context?:
Why not just generate the mapping code in the first place, then?
The mapping tools I use do have the ability to work in a number of ways, including:
a) dynamically create a list of delegates (so everything is a run-time data structure)
b) explicitly generate source code for the mapping (with the resultant source file then being added to the project)
But neither of those are really related to discoverability of a change in an automatic fashion.
The case of a "Source property" being removed has already been touched on (and prompted this discussion), but there are also many other types of changes that can occur.
Even with the Source Code Generation approach, it requires a human to pay attention (which is not a bad thing, but it is not a reliable thing).
On the other hand, having a test that looks for changes and requires human interaction to either accept the change (triggering a new generation, either of source or of meta-data) or "fix" the code hat induced the change is something that greatly mitigates things falling through the crack.
Granted there is a subjective element to evaluating the different approaches. Many times my primary goal is to enable the computer to protect the code from me, at the expense of a little bit of extra effort in certain areas.
-
@MrL said in What do Entity developers do in this context?:
@TheCPUWizard said in What do Entity developers do in this context?:
@MrL said in What do Entity developers do in this context?:
Someone changes a property name in one of data classes. Everything seems fine. Two weeks later system blows up in some infrequently used module, because mapper doesn't see the change and leaves something as null.
If it blows up, filling db with nulls without anyone noticing is also a possibility, of course.Sounds like a lack of testing. For mappers, generated tests (that are only generated and then verified by a human) should catch this type of situation.
Thing is, you use mappers for quick and easy effects. And then you have to generate and maintain tests specifically for mappers. So what's the point?
With manual data copying property name mismatch is caught at compile time.
(Emphasis mine) Manual data copying still won't detect that one or the other side gained a property.
We have tests for Automapper which have a minimum of boilerplate (basically you need to define a type which extends
MappingTest<MappingCodeType>, reflection will do the rest). Those tests do check that at least every property in the "from" type has a corresponding property in the "to" type (at least, if it's not the other way around). The AutoMapper instruction code then can be changed to have extra rules to declare this deviation from the norm, or it can even be custom copy logic.
-
@JBert said in What do Entity developers do in this context?:
@MrL said in What do Entity developers do in this context?:
Thing is, you use mappers for quick and easy effects. And then you have to generate and maintain tests specifically for mappers. So what's the point?
With manual data copying property name mismatch is caught at compile time.
(Emphasis mine) Manual data copying still won't detect that one or the other side gained a property.
No, but without mappers there's no 'things happen by themselves, I don't have to check' mindset.
We have tests for Automapper which have a minimum of boilerplate (basically you need to define a type which extends MappingTest<MappingCodeType>, reflection will do the rest). Those tests do check that at least every property in the "from" type has a corresponding property in the "to" type (at least, if it's not the other way around). The AutoMapper instruction code then can be changed to have extra rules to declare this deviation from the norm, or it can even be custom copy logic.
Like I said, you invest time and effort to test and maintain implementation detail that's supposed to save you time and effort.
-
@MrL said in What do Entity developers do in this context?:
there's no 'things happen by themselves,
Want to consider the "things that happen by themselves" in between the high level language you are using, and the actual transistors that are switching on and off??
ps: I well remember debugging CPU's to find a faulty element. The worst was a time when the carry from bit 7 to bit 8 did not propagate under very specific conditions [turns out there was a "near short" on the wire-wrapped backplane...]
-
@TheCPUWizard said in What do Entity developers do in this context?:
@MrL said in What do Entity developers do in this context?:
there's no 'things happen by themselves,
Want to consider the "things that happen by themselves" in between the high level language you are using, and the actual transistors that are switching on and off??
Not really, no.
