DLL vs WCF: Performance vs Extensibility (WCF just in case?) [closed]

Question

Let's say you want to create an ASP.NET web app. You think it will always just be a web app (with regular and mobile pages) but you never know. It's possible someday you might want to have an iPhone, iPad, Android, or whatever app as a client. If there is a 0% chance of this, you'd package your business layer as DLLs and reference them from your client. If there's a 1% or greater chance of those other front-end apps in the future, you'd package your business layer in WCF and expose via http (i.e. service oriented architecture (SOA), software as a service that any client can consume regardless of platform).

• DLL pro: speed/performance.
• DLL con: Only Microsoft clients can consume and must have DLL with client. That also means if DLL embedded with client app, then long distance to take data to business tier to process and then return.
• WCF pro: Extensibility.. any client can consume.
• WCF con: speed/performance.

Software architecture is all about finding the right balance of performance and flexibility. I guess you'd have to go WCF in this case as an insurance policy?

Answer 1

You don't have to go with WCF. If the need arises and you need to expose your BLL's functionality to other non-microsoft types, then you can create a new WCF service. Inside this new service, you can create wrapper methods in your ServiceContract that expose your DLL's methods, etc. So, you can just create your DLL and create a service for it in the future if a need arises.