|
Wrapping the Model (as in MVC, MVP, MVVM) into services is not a bad approach at all. Call the services asynchronously and take that into account in your presentation logic and the differences in behavior disappear. At least that will give them a strict separation of tiers.
Super Lloyd wrote: And I also doubt anyone is gonna do a much better job than the previous app Ok, Sheldon, give the kids at least a chance to fail before you begin to count their mistakes.
Super Lloyd wrote: i.e. I believe heavy refactoring is the way to go, and strangely enough nobody here want heavy refactoring instead, strangely enough, they believe full rewrite from scratch is the way to go Like it or not, not everybody enjoys dealing with unexpected side effects which accompany heavy refactoring. Your love for the old solution in all honor, but I have seen enough totally messed up junk that had to be put out of its misery. If only someone had kept track of the requirements and changes instead of insisting that this spaghetti mess somehow documents itself...
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
I have no love for the old solution
I believe, as a general statement, that making a new app from scratch when you have no clue about the old one, seldom result in better outcome...
|
|
|
|
|
Super Lloyd wrote: when you have no clue about the old one How many people who do have a clue are still around? And why are they not working on it?
Just how can we keep having a clue, even when people leave or are not available anymore? Is that not what reqirement management, change management and project documentation are for? If these things do not exist (except - just maybe - between someone's ears), then building it new reduces the problem to getting a clue. At least you don't also have to wrestle with all sorts of undocumented surprises as well.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
modified 21-Sep-18 4:25am.
|
|
|
|
|
We did that last year... rewriting an old system that I didn't write or knew how it worked. We ended up basically copying the old db and implementing a new back-end and front end, which at least came out looking prettier than the old one.
|
|
|
|
|
The advantage of using a web framework is that the application can be platform independent, is this needed ?
Otherwise I have my doubts, seen some things like the new PgAdmin4 for PostgreSQL that have become bloated and slow as molasses ...
|
|
|
|
|
RickZeeland wrote: PgAdmin4 for PostgreSQL that have become bloated and slow as molasses Oh noes!
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
I'd rather have a desktop app written by a web developer than a web site written by a desktop developer.
|
|
|
|
|
I would prefer the opposite. May be because I started off with Windows Forms and then moved to web. I still run away as much as possible from web front end though.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
Desktop developers struggle with the lack of state when they move to the web, this is often very evident in QA.
|
|
|
|
|
They also seem to struggle with understanding where the code is running.
Trying to use Process.Start or Office Interop to open files on the client; trying to use MessageBox.Show to ask the user a question; trying to save files in a specific path on the client from server-side code; trying to read uploaded files directly from the path in the FileName property; etc.
Of course, I think a lot of these problems are caused, or at least exacerbated, by Visual Studio. When you run the project in VS, it's an interactive process on the same computer, so there's nothing to warn novice web devs that their assumptions are wrong. At the very least, it should be a non-interactive process, so that no UI can magically appear from the server-side code. If it could behave as if it has its own file system, completely separate from the developer's PC, that would cure even more misconceptions.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Quite. It was even worse back with classic ASP as given the stuff that runs on the client and the stuff that runs on the server were on the same file it was even easier to not appreciate that the little "%" in the tag made a big difference.
Of course that paradigm has gone full circle with razor but at least people are discouraged from putting business code in their views.
I still want to know where people are learning to string concatenate their SQL statements though. What articles are the looking at to learn how to code? Ones from 1996?
|
|
|
|
|
Rewriting may not be an easy undertaken when an application is "huge" running on a particular platform. Recently, I noticed that SAP Concur (https://www.concursolutions.com/default.asp) is still a conventional active server page application. If it could be easily rewritten, SAP would have done it long time ago.
TOMZ_KV
|
|
|
|
|
I think this is a natural instinct in a majority of developers.
- That don't make it right though, mister.
Many many years ago Joel Spolsky wrote on his blog about the refactoring/rewrite of Netscape. It may have been while they were under AOL. Almost all devs pressed for a rewrite: "Nobody can make this stinking pile of horse residue good.". In the end a total rewrite was decided on. The result was a release delay of of 2-3 years as I remember it. His takeback was: "resist your instincts, do it gradually".
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
My thoughts as well!
|
|
|
|
|
Super Lloyd wrote: Here, at work, a bunch of our developer have taken over the development of a console app.
By taking over I mean they are going to rewrite from scratch a much better new one.
For now they are putting down a web like service framework which is going to componentize the app to the next level.
That's a comedy in the making right there. Except for those working with you and witnessing first-hand the app's progression into insanity, I suppose. Good luck with that. Steer clear.
|
|
|
|
|
Super Lloyd wrote: For now they are putting down a web like service framework which is going to componentize the app to the next level.
That might be a good thing, particularly if the console app might be implemented as a web app at some point, or you want a future web app to have access and manipulate the same data. One API to rule them all!
Latest Article - A Concise Overview of Threads
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Mmm.. the console app is, in fact, a hardware controller on RaspeberryPi. It ain't gonna be turned into a web app anytime soon.
What itch me the most so far is that their service architecture, so far, only support transient service, not something that be ongoing...
I just remarked that battery controllers are something on going.. not something you poll every now and then to wake up...
For example, code-wise, services with Start()/Stop()/IsRunning or Connect()/Disconnect()/IsConnected methods represent hardware controller better I believe than single Run(CancellationToken) method ones
|
|
|
|
|
WTF is this???
Techincally accurate, but practically useless.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
I miss something. In about every project I ever had the pleasure to open, The Master of the Obvious would have left something like this behind:
public int DoSometihngObscurish(string ObscureParam, decimal[] ObscureArgs, Random theObfuscator); Spelling intentional. The Master of the Obvious designs everything he writes in a way that the reader gains no information beyond the obvious and, if possible, has even more questions than before.
In this documentation the Master of the Obvious forgot one essential thing;
Quote: Summary: This event notifies some other class that a property has changed.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
This is what happened when warning 1234 informs you, you must put a comment on that method. But your heart is not into it.
Code comments are nice, but I think they should NOT be mandatory for this exact reason.
|
|
|
|
|
Code comments and code documentation are two very different things, imho
667: The neighbour of the Beast
|
|
|
|
|
Click through to the INotifyPropertyChanged documentation, there is actually a nice example included.
|
|
|
|
|
99% of .NET framework documentation is made that way - that's why I hate .NET with a burning passion. Win32 API are much better documented, and still they don't approach the quality of Win16 documentation.
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
|
This is one of those pages that proves MS's documentation is generated by an automated tool, in case anyone still needs any convincing. Pulled entirely from source code--no comments, no documentation. Which infers developers are in charge of the documentation.
|
|
|
|