|
Oh you are in for a world of hurt going down this particular rabbit hole.
Most/some lookup tables have a consequence in your code - how do you associate a new status with an action.
A generic lookup table simplifies the maintenance until you find a lookup that does not fit your structure (this always happens 2/3 through the project). I now have a table for each lookup type, I decide which ones can be edited. The delete procedure has to deal with FK and usage issues.
I recently got called a dinosaur by an out source architect for insisting on this structure, they then went down the generic path. I got a laugh when they ended up with a 3 table generic structure that was so complex the developers got lost trying to maintain it. F***ing whipper snappers.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Don't "delete", use "expiry dates" for your lookup entries; don't show "expired" ones in the maintenance views except in "browse" mode.
Insures referential integrity ... even "years" later.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
I never delete. I always use delete date. That's what I mean by delete.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Quote: Before they can remove a status I would like, to ensure that the Id isn't in use
Why?
Or is "remove" not the same as "delete"?
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
True. I don't need to remove it
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
I noticed last week that the latest version of the Node Package Manager automatically audits your installation, checking installed versions against the data base of documented vulnerabilities in the NPM Registry. It delivers a very nice report, complete with instructions for automatically fixing many vulnerabilities by upgrading the affected packages. Other package managers (e. g., NuGet for Microsoft .NET, Composer for PHP, PIP for Python, PPM for Perl, would do well to implement such a feature, and probably will soon.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
modified 5-Jun-18 17:37pm.
|
|
|
|
|
The Data Mapper pattern is an effective way to decouple the domain model from whatever data storage system the application uses. However, one thing I noticed about it is that it does not explain how and when the data mapper should be notified that it needs to update the data.
I propose that the domain object notifies the data mapper (and, possibly any other objects that are interested) when one of its fields/properties changes via an event (I use C#, which supports events and properties and have the code to publish the event in the property's getter). The data mapper can then do whatever it sees fit to do with this information. Using events also inverts the dependency between the domain object and its data mapper.
Whenever a domain object is created in memory (either read from data or completely new), a data mapper should subscribe to its relevant events. There could be one data mapper per domain object or one per type of domain object. Additionally, the logic for creating, reading, and deleting domain objects need not be in the same data mapper that handles updates.
|
|
|
|
|
I don't think that update notifications are in the scope of the pattern. The Data mapper describes how persistence is handled, not when or why.
Other patterns, such as Repository and Unit of Work, can be leveraged in conjunction with a Data Mapper in order to provide the actual update logic. This is the SOP for current MVC.NET applications with EF.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
What I'm describing is supposed to be a new "version" of the data mapper pattern.
|
|
|
|
|
Yeah, I got that. I just disagree with your premise. 
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
That's fine.
From what I read of the data mapper pattern, all it really says is separate the data logic (CRUD) from the domain object stuff (i.e. don't use the active record pattern), which, while lacking in detail is great advice.
I saw that you mentioned the unit of work and repository patterns in your previous post and took a quick look at them. I don't see how they directly relate to updating domain objects. From what I saw, it seems like the controller or something has to tell the unit of work class to update a domain object. How/where do you deal with determining how/when to update domain objects?
|
|
|
|
|
The Repository pattern is 100% about updating domain objects against a persistence store. UoW is about making those updates atomic in nature. The Repository is purpose-structured to use the Data Mapper pattern; as the entire purpose of the pattern is to define a persistence touchstone for model classes (AKA domain objects).
You can do it procedurally in a more functional/workflow model (such as the controller queuing and update) or, as you're advocating, through an event driven paradigm. In desktop applications I like to hook updates to ViewModels through INotifyPropertyChanged, for instance, so that user updates to relevant objects wrapped in ViewModels will update when the user updates them.
Event-driven updates are basically a must in any asynchronous approach, but I would argue that they need to be hooked to model handling logic rather than the models themselves.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Paramecium13 wrote: I propose
To whom?
I like the idea, but it will probably get buried under a lot of other posts in the forum. Given the paragraphs in your post, I am convinced that you can write an article about the subject; ideally, you would also explain the Data-Mapper Pattern itself, include a simple example, and add your proposed change. Aw, and pictures if possible, people love pictures
The results will then also show up higher on Google, as articles seem to be favored over forum-posts. It would also change the audience from "people scanning the forum" to "people watching the article queue for new stuff to learn". If enough people agree with your article, then it may become "the" way to do it.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Yeah. I might write an article. I figured I'd post it here first to see what people think.
|
|
|
|
|
Recognizing the growing number of applications that used two or more programming languages in their implementation, I extended the Reddick VBA Naming Conventions to cover virtually any programming language in 2006, naming the extended conventions the Reddick-Gray Unified Naming Conventions. Fast forward 12 years, and a Scottish musician living in the south of France finds a copy, and writes to me with some great questions and an excellent critique. The result is version 2.10 of the conventions, now online [here].
The work is based on Hungarian Notation because I believe they are as useful today as they were when Charles Simonyi published his paper. Though some claim that modern integrated development environments render the Hungarian prefixes moot. I think not, for the following reasons.
- Code Reviews: Copies of code that are dropped into email messages and distributed for code reviews lose the connection to the IDE tools that let you see the types of the variables.
- Git Repositories: Copies of code that find their way into a Git repository lose their connection to the IDE tools that let you see the types of the variables.
- Bulletin Boards: Code posted on a bulletin board, such as the Code Project question forums and Stack Overflow are deprived of their type hints.
- Too Many Lines to Fit on Screen: Frequently, it is impractical to keep every routine short enough to fit on one screen. Even if you adhere to the accepted practice of declaring variables close to their first use, all it takes is one long
switch block to hide the declaration.
I rest my case.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
modified 29-May-18 15:00pm.
|
|
|
|
|
The first obvious question would be whether it is based on System or Apps hungarian. After a bit reading, looks like Systems Hungarian.
X DO NOT use Hungarian notation. Hugarian notation – it’s my turn now – Larry Osterman's WebLog[^] - where "sz" is a prefix for a null-terminated string. How often did you have to convey in C# or VBA-code that a string is null-terminated instead of Pascal-style?
David A. Gray wrote: Frequently, it is impractical to keep every routine short enough to fit on one screen.
No, it is not. Any example from MSDN fits on a printed fixed-font 80 column A4 paper. Anything longer probably has more than a single responsibility and is a candidate for refactoring.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: The first obvious question would be whether it is based on System or Apps hungarian. After a bit reading, looks like Systems Hungarian.
X DO NOT use Hungarian notation. Hugarian notation – it’s my turn now – Larry Osterman's WebLog[^] - where "sz" is a prefix for a null-terminated string. How often did you have to convey in C# or VBA-code that a string is null-terminated instead of Pascal-style?
Just because Microsoft says it's so doesn't make it so. IMO, this advice is ill-conceived for reasons that I gave in my original post. As for distinguishing null-terminated from counted strings, I'm sure there's an edge case somewhere, but it's never been a concern to me that couldn't be addressed by other means, such as passing the length of a counted string, or zero for a null terminated string of unknown length.
Eddy Vluggen wrote: David A. Gray wrote: Frequently, it is impractical to keep every routine short enough to fit on one screen.
No, it is not. Any example from MSDN fits on a printed fixed-font 80 column A4 paper. Anything longer probably has more than a single responsibility and is a candidate for refactoring.
Citing examples from MSDN is an insufficient defense. I live in a real world in which not every routine can or should be that short. Moreover, what happens when your view of the source code is constrained by the many other windows of an interactive debugger?
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
David A. Gray wrote: Just because Microsoft says it's so doesn't make it so.
That should be obvious, but they're not just saying it; they have a good reason to: they have lots of experience with Sys Hungarian. I'm personally glad that we don't have to lookup/invent prefixes for every new variable-name.
David A. Gray wrote: I live in a real world in which not every routine can or should be that short.
I forgot, the 20+ years of coding on my side were fictional ofcourse 
David A. Gray wrote: Moreover, what happens when your view of the source code is constrained by the many other windows of an interactive debugger?
You learn to click the windows to "bring it to front".
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: they're not just saying it; they have a good reason to: they have lots of experience with Sys Hungarian. I'm personally glad that we don't have to lookup/invent prefixes for every new variable-name
Maybe they think those are good reasons, but they also think they are the smartest people on the planet. If you don't believe me, just ask most any of them, and they won't hesitate to tell you so.
Undoubtedly, Microsoft, the corporation, has lots of collective experience, but that doesn't guarantee that they have all the right answers. They may have answers that work well in their closed universe, where everything lives exclusively in a Visual Studio editor window. The real world isn't nearly so cloistered.
Eddy Vluggen wrote: I forgot, the 20+ years of coding on my side were fictional ofcourse
You cited examples from MSDN, and my response was based on that. I know who you are; you're another curmudgeon like me, who has been at this for many years.
Eddy Vluggen wrote: You learn to click the windows to "bring it to front".
That's no help when it's one of many windows that share the space on a desktop. Sometimes, you just can't afford to make the window too big, because you need to see it alongside several other windows, such as the Watches and Call Stack windows. Furthermore, I still do some work in C and C++, and I usually debug that code from a disassembly view.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
Before I begin; it's not personal, I'm just very sceptical with anything new. I can see you put in quite some effort and time. Anyone who doesn't like the proposed NC from MS would do good to take a look at it - having the same NC means consistency and predictability.
David A. Gray wrote: Maybe they think those are good reasons, but they also think they are the smartest people on the planet.
They do own the leading OS, the leading Office-suite, and some more. And yes, it is rather smart to ask your customers what they want.
David A. Gray wrote: Undoubtedly, Microsoft, the corporation, has lots of collective experience, but that doesn't guarantee that they have all the right answers.
Same goes for my doctor. I'm not saying that they are without flaw or that they cannot be wrong; I'm saying they have "some" experience in the field, writing some very succesfull apps and working with developers[^].
That doesn't mean that I'm a Microsoft-fanatic; there's always room for improvement, and you might be presenting a good idea - but in Garfield terms, I need to know what is in it for me. Why would I use it? What benefit does it give me? That needs some other argument than simply "MS is arrogant".
David A. Gray wrote: You cited examples from MSDN, and my response was based on that.
I tend to use that a lot, yes.
David A. Gray wrote: Sometimes, you just can't afford to make the window too big, because you need to see it alongside several other windows, such as the Watches and Call Stack windows.
Those things are integrated in the IDE, and there's a second screen/monitor dedicated to debug-windows. That's not just Visual Studio; MonoDevelop does the same.
We weren't talking about the call stack window; you were introducing a naming-convention. I can remember the list of "required prefixes" from VB6/Access, and the wastefull discussions to agree on a new prefix if there's a new control introduced. Aw, and changing all the names to adhere to the convention, which did not add any value, just bugs (=time+money).
David A. Gray wrote: Furthermore, I still do some work in C and C++, and I usually debug that code from a disassembly view.
I haven't touched either in years, so I can't say anything usefull about that situation
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I think it's safe to say that we're generally on the same page. While I spend a lot of time in the Microsoft stack, I don't work exclusively there. I suspect that comparatively few people have the luxury of doing so now, if they ever did. In any case, I try to maintain a broad, technology-agnostic viewpoint. It is from that viewpoint that I believe that Hungarian notation still has merit.
Bear in mind, too, that my chief design goal was to extend the conventions to dynamic languages (e. g., Perl, JavaScript, PHP) that don't enforce variable typing, and to devise one unified convention that can be applied to any programming language, ensuring consistency of names across entire code bases, regardless of implementation language. With respect to the dynamic languages, the conventions put forth a subset of one-character prefixes that cover only a handful of categories ( ( integer || string || object ) && ( parameter || return || private ) && array ).
Nevertheless, although I didn't say so in the RGUNC document, I quit using Hungarian prefixes for business objects a long time ago, because I think that truly is a waste of effort. More recently, I have also begun dropping prefixes from public interfaces. Nevertheless, I retain them for private entities, especially in "system" or "utility" libraries.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
David A. Gray wrote: In any case, I try to maintain a broad, technology-agnostic viewpoint. It is from that viewpoint that I believe that Hungarian notation still has merit.
Dim iCurDate As String Happened too often in brownfields.
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. Code for readability." (From some manual, and it is good advice)
David A. Gray wrote: my chief design goal was to extend the conventions to dynamic languages (e. g., Perl, JavaScript, PHP) that don't enforce variable typing
I dislike all weak languages. Makes weak programs that are based on an on error resume next philosophy.
David A. Gray wrote: ensuring consistency of names across entire code bases, regardless of implementation language
That sounds like an advantage, but why does it need to be consistent in different languages? Delphi has some weird string-types, does it make sense to unify that with JavaScript? And what do I gain by doing so?
David A. Gray wrote: Nevertheless, I retain them for private entities, especially in "system" or "utility" libraries.
If you can be consistent, then it would not be much of a problem; but if the prefixes are there, I expect them to be correct.
So, I would not oppose the use of it, especially not if one is so accustomed to doing it so that it becomes a habit and goes nearly automatically.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: I dislike all weak languages. Makes weak programs that are based on an on error resume next philosophy
I don't either, but they are here to stay. As for the "weak" languages being based on the "on error resume next" philosophy, this was once true, but modern ECMAScript, PHP, and Python support rich try/catch/finally blocks, custom exceptions, and pretty much anything else that was once reserved for C, C++, C#, and the like.
Eddy Vluggen wrote: So, I would not oppose the use of it, especially not if one is so accustomed to doing it so that it becomes a habit and goes nearly automatically.
I've been using them for so many years that they are automatic. Indeed, I have to consciously elect to refrain from using them.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
"Hungarian Notation" can be traced to a time when some languages would only support "very short" variable / db names (e.g. 10 chars); and / or case-insensitive.
Now, we are encouraged to use meaningful names (with limits rarely less than 256 chars) that are a lot more expressive than simply int vs double (which OFTEN changes), etc.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Gerry Schmitz wrote: Now, we are encouraged to use meaningful names (with limits rarely less than 256 chars) that are a lot more expressive than simply int vs double (which OFTEN changes), etc.
That is, of course, a risk that you take when you use Hungarian prefixes.
- However, when you change the type of an internal variable, renaming it is straightforward.
- OTOH, when you change the type of a parameter, you break the interface, and the new interface must be documented and published as such. In that case, renaming the argument is not only acceptable, but desirable, since it exposes references to the argument as diagnostic messages.
Nobody is forcing you to use Hungarian notation. Only a portion of these conventions relies upon them, and the remaining conventions stand on their own.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
