I'm not sure if this is the right place to post this (I'm fairly new, but Stackoverflow and Superuser suggested this site for my question), but here goes.

I currently have the following:

  • A frontend - made with WPF
  • A Dll
  • An IO-server - Hardware.

The Dll contains ways of communicating with the IO-server, and the frontend should be able to control when to open/close and also read from the IO server. I now need to make a new program to handle this.

The way it should operate, roughly, is:
You click a button on the frontend and it sends a tag (e.g "qw450") to the program i'm about to make. This then converts the tag to a function (so depending on the tag it does something different). Then it calls the corresponding function and updates the IO server acordingly. This should go both ways. So if the IO server gets a signal, the "tag interpreter" should send a tag to the frontend and update some visuals (e.g change color or show numbers)

So far I've thought of 3 different solutions and would like to know which is better and why. The most important thing will be the speed of each operation as it might be used to control emergency stops and such.

[EDIT: Added images]

Solution 1: Standalone program
Create a new program and have that implement the DLL. Then keep the current frontend and have it call the new program.

Standalone program

Solution 2: Expand the frontend
Keep the current setup and insert the way to communicate into the frontend program (in a dal layer)

Adding it to the backend

Solution 3: Create another dll
Create this as a dll and have to current frontend implement both the dlls.

As a DLL

I really hope this makes sense to you and you would like to help me. And of course if there is an even better solution i would love to hear it!

  • 3
    All of these options are valid (though I would suggest that 2 and 3 should go hand in hand). The question is what you justifiably need to use. This almost entirely hinges on the size and scope of your application. For example, additional applications are good if you want to either centralize many clients, or you want to do some gatekeeping (e.g. not giving the front-end the keys to the IO server).
    – Flater
    Oct 22, 2018 at 14:09
  • Also, is this related to OPC? Have you looked for existing solutions to your problem? I've developed several OPC applications and almost always, there was already an existing tool to do a similar job.
    – Flater
    Oct 22, 2018 at 14:10
  • @Flater Thank you for your answers! it is indeed OPC and i will be looking for some tools that might help. You said 2 and 3 should go hand in hand. Does that mean that you suggest creating another dll and communicate through that instead of just calling the current dll i have directly from the dal layer? I'm not able to up your comments but if you create an answer i'd be happy to vote for it :) Oct 23, 2018 at 7:04
  • What I meant more is that when you expand the frontend (solution), you should put your OPC wrapper in a separate database, at least as a matter of good practice (so it can easily be swapped out at any point in the future).
    – Flater
    Oct 23, 2018 at 7:08
  • 2
    "The most important thing will be the speed of each operation as it might be used to control emergency stops and such.". This is a big NO. Emergency stops can not be controlled by non-safety rated systems. Doing so means that they are no longer emergency stops, and any such configuration will fail a proper safety audit.
    – Peter M
    Feb 15, 2021 at 14:27

2 Answers 2



The most important thing will be the speed of each operation as it might be used to control emergency stops and such.

The diagrams you've shown do not inherently translate to performance differences. Pre-compilation code and post-compilation applications are very different in that sense.

What would be a much more impactful decision here, is how you translate your tag name ("qw450") into a set of instructions. That means you've got a mapping, which is stored somewhere, and where it is stored is going to be key to squeezing things for performance. Where the memory footprint allows it, in-memory data storage is usually the most performant.

Another impactful decision here is how this communication is going to happen. Since you call it a "new application", I suspect it's going to have its own runtime, as opposed to the old DLL which would just be included in the runtime of the WPF application itself? Then you need to really consider where this second runtime is situated relative to the frontend.

Is it the same machine? The same local network? An internet connection? The performance of your communication medium is always going to significantly impact the performance of your application.
Note that running things on the same machine isn't always the most performant option, in cases where you need more CPU power than your machines can provide. This is why most companies tend to separate their database servers from their application servers, as the network delay is smaller than the impact on the CPU of a machine that is both a database server and application server.

Related to this is the question whether you have multiple frontends active at the same time or not. If you do, that adds more of a reason to consider whether your second application should be hosted on a shared remote resource, or on each local machine that also runs a frontend.

Which option?

Right now, this makes the question very hard to answer. You've given us three options to choose from (or a fourth one of our own making), but the criteria for deciding between these options (performance) aren't meaningfully affected by these different options. So it's anyone's guess as to what will actually work for you best.

So instead, I'll give you a quick rundown of what each of your options will entail.

Option 1

This is the simplest way to do it. Your new application effectively wraps the old DLL and becomes its new public interface, to be consumed by your frontend.

It's simple and straightforward. Your frontend developer only needs to know your new application's interface, which in turn provides everything the frontend will ever need.

But it comes with one notable drawback: your wrapper will need to handle/expose every interaction between your frontend and your DLL.

The reason I mention this is because of the communication where the IO server contacts the frontend (instead of the other way around). You mention that this needs to happen, but you don't actually mention that your new application should do anything different than what the DLL already provides.

If that is indeed the case, this means that your new application is going to have to expose the same feature without really changing it, leading to a bit of passthrough code that adds no real value. It's not really a dramatic issue, but it's a bit of extra work with no real benefit.

Option 3

Sorry for changing the order of the options but it helps with the explanation.

Here, you've ensured that your frontend has choice. It can take the old path, or it can opt to take the new path. A frontend developer is free to choose whichever path they want.

The benefit here is that you don't have the issue from option 1. You don't need to make passthrough wrappers, the frontend can just access the DLL directly. That will save you some effort in developing the new application as you don't need to spend time writing those wrappers.

The drawback here is a matter of complexity. With choice comes the responsibility of needing to make the right choice. Your frontend developer now needs to know both the new application and the old DLL, and needs to make their own informed decision.
Whether that's good or not very much depends on how beneficial it is to bypass your new application or not.

While you may save time on not having to write those wrappers now, it's possible that in the future, your IO-to-WPF communication will need more bells and whistles, and then you'll have to migrate it to your new application. This means that the frontend needs to change the path it chooses, no longer using the old DLL.

For some added complexity, consider if only some of the IO-to-WPF communication migrates to the new application, and some of it remains untouched. Now, your frontend developers really need to evaluate when to use your new application, and when to use your old DLL directly.

The size of this drawback depends on many factors. how liable features are to change, how many features there are, how heavily you need to defend against the frontend bypassing your new application features, ....

In short, this option can streamline the development effort of the new application, but it puts an additional cognitive load on the frontend developers (by forcing them to choose between two options and ensuring they always make the right choice).

Whether or not the benefit outweighs the drawback, is very contextual and a matter of risk assessment.

Option 2

The one big difference here is that you've ensured that your new application is part of the same runtime of the frontend. As I mentioned before, though you'd usually expect this to be more performant than by separating the runtimes across network machines, you also have to consider if the local machine has enough CPU/memory to be able to run both the frontend and new application at the same time.

I would suspect so, but that's just a guess. If this is a highly trafficked scenario (which IO servers tend to be), your frontend may be a very intense application if it visualizes real-time data, and you may not want to see any hiccups (in the UI) when a complex bit of calculation logic in your "new application" is encountered.

This is something you have to decide for yourself, based on your frontend's performance requirements and the hardware you're working with.

In regards to the development benefits/drawbacks mentioned before, you can go either way with this:

  • If your "DAL Layer" acts as the sole point of contact to the old DLL, and the frontend should not access the old DLL directly, then this is the same as option 1. The same reasoning applies.
  • If your "DAL Layer" is an optional layer and the frontend is still able to access the old DLL directly, then this is the same as option 3. The same reasoning applies.

Expand today, substitute tomorrow.

You will get working software today, and once there you will gain more clarity on if any part of the old infrastructure needs to be substituted. Thanks to real life feedback, not guesses.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.