There has been a lot of news lately around the Force.com cloud computing platform and the benefits it provides to the enterprise for developing and delivering custom web applications. After spending the last 6 months designing and building enterprise applications on this platform, I wanted to put out a realistic comparison of the Force.com platform vs .Net. The reason is simple. We were mandated to use the Force.com platform over .Net to deliver the front end of our largest customer facing application. The decision was made way over my head, but I’ve been forced to live with the fallout from that decision ever since it was made.
If you don’t want to read the full post, the summary is this:
The Force.com platform is useful for building 2 types of applications.
- Applications that EXTEND their Salesforce CRM product
- The most basic of CRUD based applications
Aside from that, it’s a toy development environment for building toy applications. Serious enterprises need not apply.
The Force.com marketing team are masters in management speak and will use every hot, hip and happening buzzword they can to make you believe that you can build real applications using their cloud based infrastructure. You’ll see articles on cnet or techcrunch touting the benefits of “moving to the cloud” but the reality is far from the hype. Claims were made that we could implement our application 5x faster and up to 30% cheaper using the Force.com platform over .net. Claims were made that we could use the cloud to scale infinitely to meet our loads. Claims were made that we could build on their SOA architecture to simplify our back end integration requirements.
The reality?
So far, the Force.com platform has been nothing but an earth shattering disappointment when compared to the .Net framework we were initially intending to use.
Before I start, I should make it clear that I represent neither Salesforce, the force.com platform or the .Net framework. I have worked with .net for over 6 years on a variety of projects however I’ve only worked with the Force.com platform for the last 6 months. In that time however, I’ve been on 2 Force.com training courses, spent countless hours learning and trawling through the Force.com forums and have worked with various Force.com experts to work on a way to deliver a technical design for our front end application. With that in mind, Here’s the developer level, nuts and bolts, no holds barred comparison between the two.
The Development Environment
.Net wins hands down
As a developer, one of the first things you look at is the development environment and it’s one of the biggest letdowns when trying to build anything on the Force.com platform. In .Net however, there are few better stories around for developers.
The IDE options for Force.com are editing your code files in the browser, or using the Force.com IDE eclipse plugin. At first, you might think the eclipse plugin sounds like a great option, however our team has found the eclipse plugin so infuriating to use that they now do all their development work in the browser. The plugin is buggy, slow, unresponsive and the feature set is pitiful. For modern IDE’s the minimum is basic refactoring support, code completion and syntax highlighting. The Force.com IDE gets only syntax highlighting.
Contrast this with Visual Studio, and the story couldn’t be more different. Visual Studio support for all the first class .net languages is brilliant. Coupled with plugins like ReSharper, FxCop and StyleCop it’s one of the most comprehensive development environments available.
Moving past the IDE is the development platform itself. In Force.com you’re required to develop your applications in a sandbox. Sandboxes are hosted in the cloud on the Force.com infrastructure and depending on the type of sandbox are restricted from 10mb of data for a developer sandbox to 500mb of data for a config sandbox.
The biggest annoyance with developing in the Force.com platform is that your code cannot be built or executed locally. You need to constantly upload your code to your sandbox to build and test it. In theory it might seem like this has it’s advantages but it’s fraught with danger if you have multiple developers in your team as two developers working on the same file can easily overwrite each others changes.
It’s also slow. If you want to edit a file, that means getting the latest version from the server, making your changes, saving back to the server to see if it compiles, waiting for the response and then testing the changes.
Compare this with the standard .Net development environment where the standard setup is a central source code repository with everyone working off local versions of the code in their own environments. It’s been a tried and true development methodology for a while now and is dead simple with .Net.
So far, it’s not a pretty picture for Force.com but the development environment gets worse when you start to do debugging. Debugging in Force.com is pretty much a non-event because there is no debugger. Let me repeat that. THERE IS NO DEBUGGER. Debugging a Force.com application is an exercise in the good old printf debugging. You’re going to be writing a whole lot of System.debug statements to understand what is going on with your code.
Contrast this with the Visual Studio debugger and… well need I say anymore? The visual studio debugger is one of the best features about developing in .net. Being able to attach to process and debug executing code, add watches, inspect variables, manipulate execution order and view stack traces are all things .Net developers take for granted but just aren’t available in Force.com. Not only that, the Windows cloud offering, Azure, has an offline development mode as well as integrated debugger support so it’s hard to understand why it’s not offered by Force.com.
There are a raft of other annoyances with the development environment but these are the main ones and they’re big enough for me to want to steer clear from having to develop on the Force.com platform.
Setup, Config and Deployment
.Net wins again
So you want to create a new application to deploy to the Force.com platform. The first thing to note is that there’s no “File –> New project” in Force.com. You have to create a new developer sandbox.
Not really a huge issue except that when you create a new sandbox, it’s not going to be a nice clean empty sandbox, it’s going to contain all the Salesforce CRM objects, tabs, pages and applications. Don’t want them? Too bad, because you can’t delete them either. Even if you want to build an application on their platform that has nothing to do with their CRM, every instance of a Force.com sandbox is going to have all those standard objects in there.
In .Net, it’s complete flexibility. You want 1 class or 50000? It’s up to you. Everything you put into your .Net projects is there because you want it to be there and if you don’t want it there, then blow it away. It doesn’t have to be there.
So you get over the polluted sandbox and decide you want to start moving things around. There’s a few ways you can do it in Force.com but all of them are terrible. You can use the manual deploy tool built into the sandbox, but it’s completely manual and you have to manually recreate the deploy package everytime you want to deploy to a different environment.
There’s also the ANT based migration tool that allows you to integrate the deployment and build process with a CI tool like Cruise Control. This sounds better and it is, however it only gives you a basic script which you then have to add the objects you want to migrate manually to. It also doesn’t migrate everything like workflows, email templates or anything that is dependant on a user account. These have to be migrated manually so it’s not a completely automated process.
.Net by comparison has a number of tools ranging from free NAnt or powershell scripts to commercial applications like FinalBuilder or TeamCity which allow you to automate pretty much anything you want in the build process.
We’re currently working on a custom solution for our deployment to make it fully automated, however this is far from a good story in Force.com.
Language Comparison
.Net wins by a landslide
Force.com decided it wanted to create its own development language called APEX to run on the Force.com platform. It’s a hybrid version of Java and borrows some features from C# as well as adding in a few interesting features of its own.
The first thing that you’ll notice about APEX is the base class libraries available are tiny. Despite being a subset of java there is very little functionality that has been brought over from it’s Java roots. There’s basic email, regex, xml and httprequest and httpresponse libraries as well as your standard math and string manipulation libraries. To their credit there is some basic generics support, but I really wouldn’t call it generics support as having a generic list / set implementation.
There are some glaring omissions tho such as:
- No namespace support.
- You can’t group code into folders. Read that again. All your code lives under a single folder.
- No support for steams
- No native JSON support
- You can’t group code into “Projects” or “Applications”. It all just lives in an “org”
- Anonymous types
You can define classes, however this is where things get a little weird. “Objects” in the Force.com framework are analogous to “Tables” in an SQL Database. These “Objects” have a corresponding class created for you in Apex. If it’s a standard object like “Account” the related apex class will be called “Account” however if it’s a custom object called “Messages” then the related Apex class will be called “Messages__c”. This annoying __c suffix is not negotiable.
The Apex language itself is also very closed. There are very few extension points which means that you don’t find too many open source libraries around to help do the heavy lifting in Apex. An example of this is where we wanted to process some ZipFiles on the server. There’s no Zip base class library or any other Zip libraries around for Apex, and if we wanted to write our own, there’s no stream readers or writers so we wouldn’t have been able to do that either. There is no concept of a .jar or redistributable .dll file in Apex. If you want to pass code around, you deploy the class files into your org.
The one positive about writing code in APEX is that it makes you really appreciate C# and the other .net languages. I love nothing more than switching back to C# after a large coding session in Apex and being able to use features like linq, lambdas, true generics, anonymous types and the whole plethora of functionality that is just baked into the language.
Not to mention that there’s a whole eco-system of libraries available to extend the C# language which means just about anything you want to do from parsing JSON files to manipulating Zip files is only a project reference away.
Data Access
.Net wins
One of the features of the APEX language is their query language “SOQL” is baked in. The advantage is that the language can natively query the database and return them as objects for you, ready to use directly from within your APEX classes.
If you wanted to do the same thing in c# then you’d use LINQ, except APEX doesn’t have LINQ. It’ll just return your queries as List<T> of objects. They’re only just starting to implement some aggregate functions for the Winter 10 release but if you want to do things like nested queries, case queries, query into a custom object then you’re all out of luck. Also the SOQL language has some pretty severe restrictions on the number of objects you can retrieve via a query.
Over in .Net land however, the options for data access are wide and varied. As previously mentioned, you could use the out of the box solution of linq-to-sql, or you could bump it up a notch to a fully fledge ORM like NHibernate, LLBLGen, SubSonic or any of the other ORM options around.
All of these offer far superior options for querying your data store than the in built SOQL option offered by Force.com
Relational Database Systems
.Net wins
With Force.com you get the option of storing your data in their custom database or nothing. There is no other database engine that you can use natively with Force.com. Their database system isn’t actually too bad and will give you 90% of the things you want as long as you can put up with constructing your entire database with a point and click interface. They tout this as a feature, but if you’re trying to do automated builds, it’s a nightmare. You can’t script out the database or generate alter scripts for tables, but you can export the entire object graph and deploy that to a server.
The tooling for their database is also horrible. There’s no “Management Studio” like there is for MSSQL Server so querying for data either requires a GUI or for you to drop back into the eclipse IDE and use their horrible excuse for a querying engine. You could buy the DBAmp application from the AppExchange which allows you to query in a much more native manner but that’s about it.
There also isn’t a good story for “Point in time” backup and restores. It’s easy enough to suck the data out, but because of the multi-tennant nature of the underlying Force.com infrastructure, putting data back in means you have to do the FK->PK integrity dance. There’s no “Backup/Restore” task so you really don’t want to screw up your data.
.Net on the other hand has the ability to use whatever database system you prefer. MSSQL? Oracle? Sybase? Postgres? CouchDB? No problem. Then there’s the tooling support available for these products which is first class compared to the tools Force.com provide and they all have documented backup and restore procedures which means you can get your data back at any point in time.
Web Services
.Net wins
One of the big marketing buzzwords that the Force.com guys throw around is SOA. They’ll tell anyone in your organization that’s willing to listen that they’re running a fully Service Oriented Architecture. What they mean is that you can expose and call web services. What they don’t tell you is that the web services are hopelessly crippled so you won’t want to be trying to push too much data in or out of their services. They also only support HTTP SOAP based services. There’s no rest support whatsoever. To be fair, the webservice support isn’t terrible in Force.com, but it’s a far cry from perfect.
.Net on the other hand has a fully fledged Web Service framework called WCF which can support multiple protocols over multiple transports. It supports asynch service calls as well as having completely configurable message sizes and service timeouts.
Storage
.Net wins
There’s two types of storage you’d be interested in with Force.com com. Data storage and file storage.
File storage isn’t a great story. If you follow the cloud computing space you’ll know that Amazon has some awesome storage options with their EC2 product. It makes storing documents in the cloud insanely cheap and you’d think that Force.com would have a similar option. Turns out they don’t. You can store some documents on their infrastructure, like logo’s and css files, but you can’t use it as a document repository because you’ll run out of space pretty quick.
We ended up having to use Amazon as our document storage solution, however we had to interface with a .net backend to get the documents up onto EC3 as it wasn’t simple in Force.com because of the limitation of the Apex language.
With .Net you can store your data anywhere you like, including local file systems or in the cloud. Azure even offers “blob” storage with a maximum individual file size of 50gbs.
Data storage isn’t too bad, however you will be limited to the maximum storage limit of your account and each row counts for 2k regardless of how big it is. You will also be looking to only store tens of gigabytes of data, rather than terrabytes.
Unit Testing
.Net Wins
The Force.com has support for unit testing, via their inbuilt unit testing framework. Tests run against the server however if you look at their best practices article on unit tests, they get a little confused about the difference between a unit and integration test. It isn’t a bad integration testing framework but it’s not a good story when it comes to writing true TDD style tests.
There is also no mocking frameworks available so you’ll be hand rolling all your own mocks and stubs.
.Net on the other hand has a plethora of unit testing and mocking frameworks which make it so much easier to develop code in a true TDD fashion. It’s a pretty well documented story and .Net is a clear winner.
MVC Framework
.Net Wins
Another much vaunted feature of the Force.com platform is their “MVC” web framework. The use the term MVC fairly loosely as it is true that they have Models, Views and Controllers, however there really isn’t too much care taken to ensure proper separation of concerns. The views are tightly bound to controllers and the only way you can invoke an action is through a view. Views are also tightly bound to models, rather than viewdata like in other frameworks so whilst it could be classed as MVC, it’s kind of missing the point.
The .Net MVC framework is a much closer representation of how an MVC framework should work. Views are completely independent of controllers and controllers can be invoked independently of views.
The other major failing of the Force.com MVC framework is that the only thing it will return is a page so the only way you can get data back in a semi-restful way is to create a page and call that page directly. As a result, there’s no simple way to get back data in another format such as JSON or XML unless you implement a page which acts as a template for that data.
The Force.com platform also has no concept of Model Binding, doesn’t handle post and doesn’t properly conform to URL parameter standards.
To be fair, a lot of these problems can be mitigated if you use the built in visual force components, however if you want to use a client side framework like jQuery or Ext.Js to create a rich internet application then you’re going to find it hard going.
There are other annoying things with the Force.com framework that I guess fall into the MVC category. There’s no sever side caching of objects or resources. There is limited support for accessing the HTTPRequest and there is no support for extending the framework.
UI Framework
Within the Force.com platform you can build custom web pages using their “VisualForce” technology. It’s basically a poor implementation of webforms. If you’re happy with the standard Force.com UI look and feel, then you’ll be just fine implementing your applications using VisualForce, however if you want a rich user experience, then VisualForce falls apart pretty quick. The UI components are not consistent, the layouts are cluttered and they can be confusing. It doesn’t play nicely with jQuery and it makes a lot of mistake that the original ASP.NET webforms framework made such as:
- Sending around massive amounts of viewstate
- Injecting HTML in places you don’t really want HTML injected into
- Auto-generating ID’s so that it’s hard to predict what they’ll be
VisualForce also has a set of “Ajax” controls. The way they work is very similar to the ASP.NET UpdatePanel. It’s not true ajax and if you don’t fully understand the VisualForce page lifecycle you will end up in trouble.
There are other annoying things with VisualForce such as the tabs being difficult to customize and not being able to have a second level of navigation. There is also a massive amount of javascript injected into every page.
The most annoying feature of all tho is that every element on a page must be bound to an underlying SalesForce object to take advantage of VisualForce. If it’s not, then you’re on your own and you lose all the supposed benefits of using VisualForce.
In .net you get webforms or the MVC framework and both can be tweaked to go from drag and drop coding in web forms through to complete control over the HTML that gets emitted in MVC. Webforms 4.0 also improves on a lot of the current pain points in Webforms 2.0 so it will move even further ahead.
There’s also tons of third party support from third parties with control packs for everything from DatePickers to Grids.
Security
.Net wins
The Force.com marketing guys will tell you that their security framework is one of the greatest features available on their platform. They have 2 levels of security. Role/Profile based and a concept they call “Sharing”. The role based security model is very basic and is based around a simple one way hierarchy. Users can only belong to one role.
I have to admit, the sharing feature is pretty nice, but you have to understand it fully to be able to leverage it well.
As a basic security model, the Force.com solution is adequate for basic solutions, however there are a few major problems. First, you can’t assert from within code what permissions a user has. This makes it hard to control security if you want to secure anything other than the pages that are displayed.
The security model is also not extensible. If the security model doesn’t work for you out of the box, then too bad because that’s all there is.
The security model for .Net is a bit of a different story. You can use their built in Membership and Authorization providers out of the box, but if that doesn’t do what you want, then you can extend, or even build your own one from the ground up. You can also use other 3rd party security providers.
Logging and Exception Handling
.Net Wins
This is an area that Force.com really needs to improve. The logging and exception handling really is pitiful when compared to the offerings available on .Net.
Basic logging and exception handling is available but the customization options are limited and the logs are only available within the Force.com platform. If you’re a large enterprise, you’re going to want a centralized logging solution and Force.com just doesn’t have the ability to write logs anywhere outside of the platform.
It’s not really good enough either, when you consider that libraries like log4net and NLogger have been around for a long time now and the functionality they provide is pretty much the minimum standard.
Throw tools like ELMAH into the mix to capture your unhandled exceptions and there really is a nice exception handling and logging story for the .Net framework which highlights a massive hole in the Force.com offering.
Best Practices
The thing that irritates me the most about the Force.com platform is their apparent disregard for best practices. If you take a look at the SOLID principles, it’s like the Force.com guys set out to build a framework that breaks every one of these principles.
The single responsibility principle is ignored by the way you are forced to put so much logic into controllers
The open closed principle isn’t even possible.
DIP isn’t possible, but then again, you could argue that it isn’t necessary because even if it was possible, you can’t actually inject anything into the Force.com framework.
ISP is sorta possible, but you have to work really hard to make it happen because of the ridiculous inline SOQL they encourage you to write everywhere.
Then there’s the unit tests which aren’t really unit tests. They actually actively encourage you to write fragile test that are difficult to maintain.
The list goes on and on but the point is that if you’re looking to develop an application on the Force.com platform you better be willing to sacrifice good coding practices.
So what is Force.com good for?
As you can probably tell, I’m not a huge fan of the Force.com framework, however there are 2 things that the Force.com platform is good for. The first is building applications that extend the SalesForce CRM. This is where the framework excels, but if they’re being honest with themselves, so it should.
The second is if you’re building very basic, data driven, crud based apps. You can get something up off the ground very quickly and easily, however there are other .net based tools like IronSpeed that will do a similar job. If you’re doing anything at all that isn’t based around a simple CRUD based interface then you’re going to struggle to find that Force.com meets your needs.
Conclusion
The reality of the situation is this. Force.com is a cloud based platform that has tried to position itself against the big players like Amazon, Google and Azure, however the platform they’ve delivered falls a long way short of what the big boys are doing. They’ve built an environment that will appeal to beginners because it allows them to get up and running quickly, but for enterprise grade web applications, it simply doesn’t offer the flexibility that the Amazon and Azure platforms provide.
It is also very heavily geared towards supporting the Salesforce CRM and as a result a lot of short sited technical decisions have been made which makes the platform weaker overall.
Overall, the Force.com platform suffers from many problems, some large, some small but together they create so much friction that there really isn’t a compelling reason to develop applications on the Force.com platform.
If you are building a medium to large application and want to leverage the benefits of the cloud, you’ll find much better value in using the products offered by Amazon or Azure.
From a framework point of view, there are so many things that I take for granted in the .Net framework that just isn’t available within the Force.com platform that there just isn’t a compelling reason for developers to learn the platform.
