Web Service or DLL?

Question

I'm creating an app that needs to be accessed by both a web front end hosted on an internal network and also run as a scheduled task. Nothing will need to be accessed outside of our internal systems and once the app is up and running we don't envisage anything changing for some time.

My initial thought is to create a DLL encapsulating the bulk of the necessary functionality and then call it via both a Web Forms interface for manual execution, and a console app running as an automated (daily) scheduled task.

Another suggestion has been to expose a Web Service for the core functionality instead, but as the app will never need to be called by an external resource I think the extra effort required in implementing a Web Service might not be worth the hassle. The DLL solution should also be substantially faster(?).

My question is which route would you choose? Are there any pros/cons that I haven't covered? Any glaring omissions?

Disclaimer: I'm new to .Net but due to one of our developers being involved in a serious accident I've been asked to step up to the plate.

Answer 1

You're right, web services are a lot of hassle from experience and much slower. I suggest - do a PONO (plain old .net object), but use interfaces. Look into Spring.NET framework - it can export this object for you as whatever type of (web) service, so you don't need to do the plumming. On the client side, you can also use spring to do the dependency injection and decide if you want in-process DLL or web service implementation, just by changing value in the config file. Also Spring has Quartz scheduler integration, you might want to look into it too.

Answer 2

Personally, I say go with the DLL. It will be fast and simple.

With a web service, you will need to think about your network, firewalls, performance, etc. It also makes it harder to debug since you won't be able to step into the web service from your clients, you will have to set breakpoints on both sides of the calls.

The other problem with web services for you is that you need to be much more robust handling failures. With a DLL, you know a call to a method is going to succeed, but with a web service, you will need to be prepared for that call to fail or time out whenever you make any call across.

Lastly, if you find a need for a web service at a later date, you should be able to fairly easily convert the DLL into a web service with minimal retrofitting.

Answer 3

Personally, I'd do what you said; put my logic in the DLL. Then use the DLL from your app, webservice, and what ever yet to be determined interface they request in the future.

Answer 4

Right now there is no need to create a webservice. You just would have to maintain an other IIS service on your server. If you later on create some interface that will need that DLL you can simply refer to it. So there is no need to do it preventative.

Answer 5

Using DLL is a right way, it is faster and it provide freedom in future to create webservice with using these dlls(if required) with more security over webservice.

Answer 6

We really need more information. Its difficult to answer with out knowing what exactly you requirements are. The layered approach(dll/separate class) is simple and fast. A tiered approach(web service) will let you have one environment and gives you more abstraction. You can change the code behind the web service with out changing your clients.

But In order to evaluate this we would need to know what your project is what this dll will do. Otherwise you are just hearing peoples preferences.

Answer 7

Encapsulating your logic into an Assembly would suffice for your solution, since it seems the nothing will be leaving the boundaries of your domain, both your internal applications will be using functionality exposed by the component you design.

In the interest of maintainability you could load this Assembly from a URL pretty easily, and down the line if this component needs to be wrapped into a Web Service, its certainly possible, and your code can then create web proxy classes with minimal code changes.

Answer 8

i am developing a similar application. the approach ive taken is to have my extraction logic in dll's. this is exposed via a webservice. i find web services simpler as i dont need to deleop interfaces or expose my objects ( i use classes to encapsulate data ) on the client. i then have web developers and winforms developers write their own presentation layer. while there are pros and cons( wont go into them) web services are simpler as i have a single layer. using remoting, i need the extra interface or client side library whihc has to be installed on each client. this way, i manage just the server side while the different GUIs are independant. i just like loosy coupled coding. we run numerous windows services which also use the webservices. ours is a credit card org and we interact with numerous systems. web services give use the most flexibility.

after all that, it boils down to your own personal preference taking into account your requirements. i'd would say, dont choose 1 over another without considering the ability to make changes with minimal effort. i have found rad applications to quickly change with new requirements continually added. take your time, condier the scope and lifetime of your project and the needs. then develop to your strengths.