Outsourcing add/edit of records to separated exe files

[Otto]

Pros Cons of Outsourcing for add/edit of records to standalone exe files

Hallo,
I am thinking about to outsource add/edit of records to own exe files.
I mean in the case of add/edit I would call with shellexecute this standalone exe.

Thank you in advance for your suggestions.
Best regards,
Otto

[Enrico Maria Giordano]

Otto,

what is the reason for this decision?

EMG

[Otto]

Hello Enrico,
I think one can take out complexity from a program.
You can start in a legacy app a new programming concept.
And updates are not so risky because not the whole application is addressed.
I think you can also uniform the look of your program.
Better for sharing work in a company.
Easier to find Errors.
What do you think.
Best regards,
Otto

[Enrico Maria Giordano]

Otto,

I don't know. I wouldn't use separate EXEs. Better use separate functions or classes or PRGs or LIBs, and so on.

EMG

[James Bott]

Otto,

1) I think one can take out complexity from a program.

It would seem you are just moving some of the complexity to another program. So as a whole it is still just as complex. And you likely will have to have copies of the same code (or different code that does the same thing) in both EXEs.

2) You can start in a legacy app a new programming concept.

This has some merit, but what is the new concept? You are already using OOP and I can't think of any better concept to reduce complexity and encapsulate program logic.

3) And updates are not so risky because not the whole application is addressed.

OOP and encapsulation is one of the best ways to reduce risk.

4) I think you can also uniform the look of your program.

I think you could do that either way--in the current app or in a split app.

5) Better for sharing work in a company.

How so?

6) Easier to find Errors.

OOP is great for that.

I get the feeling that you are not fully utilizing the capabilities of OOP. Are you using buisness objects or just database objects?



James

[Otto]

Dear James,
yes you are right.
But I have a feeling it could be better dividing the program.
Therefore I posted the question.

When I read your post one thing immediately came in my mind.
Time reduction during testing.

Addedit.exe 123
Calls the addedit program for the customer address number 123.
In an all in one program I get the start screen then I have to select customer management and then edit.

I do use business objects.

Your post does not say that the way is wrong you say if I understand all well you say it is not necessary to do.

But do you see any disadvantages in dividing.

Best regards,
Otto

[hmpaquito]

Otto,

I advise against using calls to external executables. How to know if an operation was successful or not? Eventually complicate programming: users, access, antivirus, firewall blocking .exe, etc ..

In cases that it is not choice but advise pass all parameters in a file addedit.exe FiParam.txt or FiParam.xml

It is true that sometimes the use of calls to external .exes is imperative. I found another use: simulate multithreading. But I find that the reasons why you want to do does not need to call an external executable.

My two cents.

[James Bott]

Otto,

When I read your post one thing immediately came in my mind.
Time reduction during testing.

There are two things I do when testing. Either make a temporary direct call to the routine being tested from the Main() function of the app. Or, I just create a temp file that passes sets of data to a routine and outputs the data to a log file so I can then review the results. If you are testing calculation or processing routines, then you can fully automate testing. If it user interface testing, then you can only bypass the opening steps to get to the UI.

James