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 envision 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

I can't believe the answer accepted was the one that adviced you to use a DLL...

"we don't envision anything changing for some time."

That's why we then have to spend time fixing the issues created by devs making these decisions. Don't think just about today, think about tomorrow. Database stuff should be hidden from client, what if you have to add a new client, and tomorrow a new one?? Build proper contracts and use services, web or not.

Answer 2

Wow wow wow. They all share one DB? If that's the case, no, no, and no. If the DB is NOT shared, then it's definately DLL.

The correct choice is Web Service. The reason is very simple too.

1) Consistency of domain model and business logic. Lets say you store an enum in a column, and you add an enum and deploy to one application. It will now break the other two applications.

2) Ease of deployment. One change = one deployment. If it's a dll, one change = 3 deploy.

3) DB transactions and concurrency control. A lot easier to resolve it in one app domain.

As for Cons suggested by others, I find them being too partial.

1) Difficulty in debugging across app domain. You should publish the possible exceptions through WSDL as fault exceptions. The calling client should handle those fault exceptions appropriately as well. It's also incredibly easy to setup unit tests and mocks on both calling client and server. Breakpoint is not the correct way to debug and work with distributed applications. You can, and it's not difficult. I just don't believe that's the correct approach.

2) Performance. WCF allows you to set different bindings through configuration. From basic http (which is easier to debug) all the way down to named pipe which you can use to obtain near-native call performance. This decision can (nearly. There are a few quirks with different binding that you need to take into consideration.) be decided after development too.

3) Security. Saying WCF doesn't handle security is hilariously wrong.

Lastly, real cons from me:

1) More complex. Agreed. Different context makes application design more difficult. That goes two ways tho. This complexity enforces clear separation of tiers. Presentation context should stay where they are, at presentation level.

2) Require more planning. Designing contracts for WCF Web Services is an art in itself.

3) Management overhead for configuration. Can be daunting for newer developers, but I hope you can get over this hurdle quickly. WCF configuration is a double edged sword, powerful, yet complex (for some).

My personal experience is, anytime a DB is shared and the DLL is used across multiple app domains, I regret that I didn't hammer the dev team enough to go with Web Services route.

So what was your final decision? It's been four years now.

Answer 3

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.

Answer 4

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 5

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 6

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 7

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 8

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 9

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 10

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.