COM - dll vs exe. What are the pros and cons? 1

[insania]

Hi,

I'm using Fox 8, and I'm looking into the possibility of writing an Automation Server, but I'm not sure whether it is best to go down the in-process(dll) or out-of-process(exe) route. From reading the Fox Help, I initially thought that the dll would be the one to go for since the in-process is quicker.

However, after experimenting a bit, it would seem that using a dll means that all User Interface (message boxes, etc.) is out of bounds, which seems a little restrictive.

I am after four things really:

1) Does anybody know whether in-process(dll) is markedly quicker than out-of-process(exe), or is there not enough in it to make it a deciding factor?

2) Is there any way of dealing with User Interface with dll, or does all User Interface have to be done by the client using data passed back from the dll?

3) Generally, what are the pros and cons of the two approaches, other than those already mentioned?

4) Is there a better alternative to COM that I should be looking into instead?

All help will be much appreciated.

 

[DSummZZZ]

1) I don't think you will notice a difference for a few instances of the server. After that, it depends on how many instances will be running.

2) Since the process is basically running in the background, there is no person there to view the user interface. A modal window such as a messagebox can hang the process. You will have to write any messages you would normally just display, to a log file or something if you want any sort of feedback.

3) Look again at the help file and see if any of the commonalities would affect you such as public variables and data sessions.

4) That pretty much depends on your needs. Care to elaborate?


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[insania]

Thanks, Dave. I should have given a bit more info in my first post. We have a stock control app that allows users to take orders, despatch goods and the like. At the moment, I specifically need to write some code that will create a sales order using parameters we have passed, which I could do just fine without resorting to dll's and the like.

However, it occurred to me that if I wrapped the code up into an Automation Server, other apps could, in theory, call the same code and create a sales order in our database. In effect, it would be the beginnings of an API... So that's how I started looking into COM.

The way I am envisaging it working is that we, or some other developer, would write some code that would read the sales order data from wherever - csv file, website database, xml file - and then call the COM Server, setting properties using the data that had been read. The COM Server would then deal with all the complexities of validating the data and the business rules before actually creating the sales order in our database.

We already have a load of classes that, in theory, we could use in the COM Server, but many of them show Message Boxes and the like. If we went down the dll route, I am guessing that these classes would have to be rewritten to exclude the User Interface elements.

So, in light of that:

1) Is COM the sort of thing I should be looking at?

2) If so, will the dll route give us advantages that would make the re-writing of the existing code worthwhile. I'm quite happy to take the pain of re-writing the existing code, if it's going to make the app more robust in the future.

I hope that explains a bit more clearly what we are trying to do, but let me know if you need any more info.

 

[Mike Gagnon]

1. Messageboxes need to be responded to, how would you handle that?
2. This will not make you application more robust since that code allready has been tested elsewhere, but it would seem to me that creating this DLL would make things more flexible for other applications to use this DLL.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[insania]

Thanks for the responses. I'm away for the weekend, now, but will reconvene on Monday and respond to any input from over the weekend. Hope you all have a good 'un.

 

[craigber]

A COM Automation Server is definately a good way to go. What you are doing is all business logic and good application architecture says you shouldn't have any UI there. Look at using a DLL and hosting in on a server running under COM+. There are articles on my web site that show how to do this.

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com

Author, CrysDev: A Developer's Guide to Integrating Crystal Reports"

 

[Mike Lewis]

Insania,

In addition to the good advice you've been given, I'd add the following:

- A DLL will be slightly faster (because Windows doesn't have to do the housekeeping associated with launching an EXE). But in practice, I doubt you'll notice any real difference.

- If a DLL crashes, it takes down your entire application (because it shares the same memory space). If an EXE crashes, it doesn't affect your application. Again, that might not be an important difference in practice. If the COM server crashes, it might be better not to try to continue with the main application.

My own rule of thumb is to favour a DLL, except when I need to run the server on another computer, in which case I would use DCOM and an EXE. I've only ever done that once, and it was a hassle, but I put that down to my ignorance in these matters.

By the way, the articles that Craig Berntson mentioned are very helpful.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Mike Gagnon]

We also use DCOM+, but instead of a making the DCOM call from the client to the server, we have a generic function on the client side that "transports" the function call to the server and then makes the actual call to the DCOM (which at that point because a regular - and faster - COM call). You gain a little speed of the big queries.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[insania]

Thanks a lot, everybody - Craig in particular, for the links. It's good to know we're thinking along the right lines. I will digest, and more than likely come back with further questions. Much appreciated.