Phil Bernie Consulting

I’ve spent a fair bit of time in the last few months analysing how we can use the security controls within Force.com to meet our business requirements. What I’ve found is that for basic applications with basic security requirements, the built in security controls provide more than ample coverage, however when you start to get into complicated security scenarios, things start to fall down a bit.

Security on the Force.com platform is broken up into 2 functional areas. The first area is data access security and the second is page level security.

Data Access Security

I don’t actually have a problem with the implementation of Data Access security within the Force.com platform and actually quite like it. I’ve found it to be flexible enough to plug in to, whilst having sensible defaults so that we can leave it alone in a lot of situations.

Data access is governed by two things. Your org wide defaults for an object and a secondary concept called “sharing”. The two work in tandem to provide fine grained control over who can see what data in an application. There are some really good articles around that provide more detail on how sharing works. Jesse Lorenz’s article provides a great overview of how you can use sharing to secure your data and for more information you can always look at the doco. The point I want to make about sharing, is that it’s an excellent way to secure your data within the Force.com platform. The ability to provide manual sharing rules, as well as create those sharing rules within code mean that you can easily and reliably secure your data within the platform.

The only drawback with the data access security is that it’s tied to the notion of roles. This isn’t going to be a problem for everyone, but it is going to be a problem for people trying to make multi-tenant applications. The basic problem is that roles are built in a hierarchy and each role in the hierarchy has access to all the data that it’s children can see. When you’re building a multi-tenant application you need to be aware of this as there is no out of the box support for putting up “Chinese walls” between each set of data so that the data for each tenant in your application is discretely isolated from each other tenant.

What you can do, is create a role hierarchy per tenant, which will provide these Chinese walls, but it means that for each tenant you bring on, you’ll need to set this up each time, or you can move them out to partner portals, which provides another way for isolating customer data. It’s a bit tricky to get your head around at first, but the main point is that you need to be aware of how roles and data access work if you’re planning to build a multi-tenant application otherwise you could end up with users accessing data they shouldn’t be.

Profiles are the second mechanism for implementing security within the force.com platform and they controls your page level access as well as what actions you can perform on particular objects within your force.com application. This sounds good in theory but there are a few drawbacks that really hurt us when we started to get into the finer requirements for our project.

Users can only belong to a single profile. This was a massive sticking point for us because we had many situations where a user may have been required to belong to a number of profiles. Consider we were building an application for a school and we had the following profiles:

Faculty Admin
Permanent Teacher
Casual Teacher

Each profile then had the following page access:

	Faculty Admin	Permanent Teacher	Casual Teacher
Create Student Page	Y	N	N
Create Student Report Page	N	Y	N
Student Attendance Page	Y	Y	Y

Suppose you had a user that was a Faculty Admin and also was a permanent teacher. They would need access to all three pages in this matrix and currently there is no profile that offers that functionality. The solution within Force.com is create a “hybrid” profile called “FacultyAdminTeacher” and give them access to all three pages.

This isn’t such a big deal with a small number of profiles, however if you’ve got a large number like we had, it quickly becomes an administrative burden because not only do you need to create the base profile and the hybrid profiles, you also need to make sure that any changes to those base profiles are then propagated to the hybrid profiles.

You cannot assert what permissions a user has. This was another sticking point for us. With profiles, you can see what role or profile a user has, but there is no easy way to assert if a user has read or write access to an object. This is annoying because once you start writing custom services or custom visual force pages, the only easy way to determine if a user actually can perform the action they’re about to try is by trying it and catching the error.

This then leads you into the spiral of letting exceptions control your application flow as well as not being a particularly nice experience for the user. You can sort of get around it be looking up if the user has the permissions set in the sharing table of each object but it’s neither elegant nor scalable when you have to make these queries for every action you’re trying to perform.

You can’t easily extend the security model. This was another major annoyance I had with the security model. There was no way to add additional security attributes to a profile so the only things that can be controlled by profiles are access to standard / custom objects and access to pages. If you wanted to add a new attribute to “assert” against like a set of function points, then you’re on your own.

It’s hard to conditionally render page elements based on profiles. There is some support in Force.com to conditionally render page layouts, however you have to use custom page layouts to do it. In other frameworks, you could tie a specific UI element to a role or function point and have a single layout which renders differently based on the role or function points available to a user. This isn’t the case in Force.com where you have to create a new layout for each representation of a page that you’d like to display to a user. It’s ok if you only have a couple of different layouts, but we have a different layout for not only pages, but individual UI elements within the pages and profiles made this a nightmare to manage.

You don’t get element level security. This ties into the previous point and whilst it is sort of possible, there really isn’t an elegant way to wrap a page element up in the profile based security especially if you’re building custom visual force pages.

All in all, I think the security model in Force.com isn’t too bad if you’re building applications with fairly simple security requirements. If your security requirements start hitting the limits of what you get provided out of the box then you’re going to really want to sit down and take the time to understand how the security controls work before just assuming that the security controls will work for you.

In my last post on Force.com vs .Net I looked at some of the areas where the Force.com platform really fails. My point in that article was to highlight some of the serious deficiencies the Force.com platform has from the point of view of a developer who has spent the last 6 months working with the platform.

To show I’m not completely biased I thought I’d look at a few areas that Force.com does a good job.

The first area is in performance. The interesting thing about the Force.com platform is that for all the negatives I had about it in my previous post, I can’t deny that it is lightning fast, which for me is it’s saving grace. As an example, we were planning to build a wizards application that would be composed of multiple steps. Our wizard engine would have to save data between each step in the wizard. In our initial prototyping, we felt that we would need to build a caching layer between the wizard engine and the database to keep the application responsive. When we built our prototype wizard engine, we were a bit worried because the Force.com platform doesn’t actually support caching. What we found though, was that the caching layer wasn’t required because we could persist the data direct to the database between steps and the server would still respond in under 200ms which was more than responsive enough for our clients.

The next area that we found Force.com provided a decent solution was for the 30 or so admin screens we had to create for our internal staff to make data changes. For our external facing site, we had to provide a rich user experience which the standard visual force pages didn’t provide, however for simple data entry and maintenance screens, we were able to easily create them and expose them internally in very little time. In general, if you’re creating data centric applications that are driven by standard CRUD operations, you’re not going to have too many problems with the Force.com platform.

The final area that the Force.com provides benefit is that there’s obviously no infrastructure involved. Force.com manages all this for you and this is where you’ll get some of your biggest wins by moving to the Force.com platform. If your applications can be structured in such a way that they can be deployed entirely inside the Force.com platform then you’re never going to have to worry about buying and configuring severs, monitoring them, keeping them up to date etc. It really starts to paint a rosy picture when you think about how spinning up a new dev or test environment is really quite simple and as long as you haven’t hit your sandbox limits. You’ll be able to setup a new environment in no time. You need to make sure you have a rock solid migration strategy for moving your applications between environments, however if all you want is a new environment for testing or doing some prototyping, it really is straight forward.

However, you need to be aware that this “no-infrastructure” situation is what will get touted by the marketing guys as where you’re going to get your ROI but you will only get that ROI if your application can be built entirely within the Force.com framework. It annoys me when I see stuff like this ROI calculator from Xceliant because it’s typical of the Force.com marketing claims that you will get 5x ROI but the reality is, any business that makes a decision based on the claims of marketing or a calculator such as this would be a bigger fool than the people that made the calculator.

An example is the situation we had where we wanted to build a dynamic templating engine which would take a user defined template and merge it with data from the database and produce a PDF report. We investigated various solutions including applications like Conga Merge however the reality was, that the limitations of Apex meant we needed to create an externally hosted service to generate the reports and then feed them back into SalesForce. As soon as we did that, we were not only back into buying hardware and infrastructure, we also needed to create an integration piece to push the data to the reporting service.

Another area we struggled with was the online analytical processing. To be clear, Force.com will not give you any benefits for OLAP type reports. Just like any OLAP process you still need to suck the data out into a warehouse, build your cubes and run your analytics off that and there are plenty of applications on the AppExchange that make this easier.

Other types of application that you will struggle to build in Force.com are:

• Anything that needs to be performing high volumes of transactional level calculations, like calculating fees for insurance premiums. The way DML is structured means it doesn’t take advantage of set operations like a normal RDBMS
• Any application that needs to dynamically generate reports based on the data used to render the report. For example, generating a report with a different logo for each client isn’t straight forward
• Applications that need to manipulate images or any binary type of data like zip files because the apex BCL’s just won’t support it
• Any application where you need to store large amounts of documents. If you’re thinking of building a Flickr clone, Force.com isn’t going to be a great platform for you
• Any application where you want to have a “multi-tennant” environment. The security model in Force.com is heavily geared towards a single tennant style of solution. If you have multiple tennants living inside the same org, you will find you’ll need to enhance their security framework.

The point is that just like any technology stack, you need to make sure you do your due diligence to ensure the technology meets your needs. If the Force.com platform meets your needs, then you’ll definitely see benefits by using it, however if you’re building a class of application that doesn’t fit nicely in the Force.com platform sweet spot, then you’ll struggle to realise any real ROI.

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.

1. Applications that EXTEND their Salesforce CRM product
2. 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.

I was reading a couple of posts the other day and it got me thinking about my current work situation. The first was a post on Coding Horror called Learning on the Battlefield and the second was Scott Hanselman’s post on Sharpening the saw for developers.

I often try to think of ways to learn new skills and actively try and learn about the latest patterns and concepts and it’s great to fill up on “theory” but so far I’ve found nothing better than rolling your sleeves up and getting your hands dirty with some code to really “Sharpen your saw” so to speak.

I’ve been doing a lot of work on a project that has had me writing and reviewing a lot of SQL code and it highlighted a couple of deficiencies in my SQL skills so I was glad to be brushing up in that regard, but that wasn’t what has interested me most about working on this project.

It has been surprising to notice there’s an underlying skill set that is being developed that is not as recognizable as the direct skills you’re learning. I’m finding more and more that it’s becoming easier to know where to apply different skills depending on the situation.

As I think about it, it has become clearer that the benefit of experience isn’t so much what you learn, but where you apply what you learn.

Take a high quality grad developer and a high quality senior developer with 5 or 6 years experience and ask them to learn about a technology. All things being equal I would expect them to learn the technologies equally well. The difference between them is how they use the technology.

More often than not the grad developer will take the approach of learning a technology and once learned find everywhere it can be applied.

A good senior developer will take the approach of learning a technology and evaluate whether or not it can be suitably applied to a given situation.

Of course these are just blanket statements but the more I look for ways to differentiate between the good developers and the great developers, the more I realise the differentiator is not what they know or what their skills are, but their ability to quickly and consistently choose the right way to solve a problem.

It’s not just good enough to solve a problem. Nearly any Joe Developer can solve a problem. It’s the ability to quickly evaluate and then decide on the optimal solution is what makes the difference. The better the developer the quicker they’ll discover the pitfalls of an incorrect solution. The best developers can not only say why the solution they chose is optimal, they can articulate why they solutions they discarded are unacceptable.

So where does experience come into this? Well there are a few exceptionally talented developers that will consistently choose the right path, no matter the situation, however for the rest of us, we need to actually experience the pitfalls before we can understand why a solution isn’t optimal and where it can be applied in future.

It’s experience that tells us that NHibernate is a good fit for a complex domain project, but may be overkill for a simple console application that only updates statuses on a few rows.

It’s experience that tells us that MSSQL reporting services is a good fit for our basic reporting needs, but we will need something more comprehensive for reporting against our data centre with terrabytes of data.

And it’s experience that gives us the knowledge to make these decisions early in the process instead of committing heavily to a suboptimal solution.

Whilst I would never hire on experience alone, in future I will be keeping a keen eye out for talented developers that have a diverse range of experience and can talk me through their thought process when choosing a particular solution to a problem over others.

I’ve been working with a tool called Tibco DataExchange the last couple of weeks and it’s been frustrating. The problem with Tibco DataExchange or “DX” as it’s known is that it’s a development tool, designed to provide a level of abstraction away from the “code” however it provides you with no way to drop back to view the code. It’s just magical fairies in the background doing what it thinks best and I hate it.

I don’t have a problem with visual tools that assist in making coding easier but I do take exception to tools that think they no better than you, and as such, hold you hostage to how they feel like implementing their solution.

A lot of people complain about the “drag and drop” mentality that Microsoft take to a lot of their development tools, however one thing they get right is that their visual tools are often little more than code generators. You can always drop back and work right in with the code.

The same can’t be said for DX.

I’ve worked with many visual tools and the best ones always have the same properties.

1. They excel at the basics and make it easy to leverage them to get up and running quickly so you get a good amount of benefit from them early.
2. They know their limits and get out of the way when you need to start doing some really heavy lifting.

Take a look at any visual tool and the ones you like will have these properties. They do what they do well and once you get to the point where they can’t help you anymore, they get out of the way.

Windows live writer is a good example. It makes writing blog posts dead simple, but if you need to make a custom layout change, you can drop to source view and do it yourself. It shows you exactly what it’s doing under the covers and lets you decide if that’s really what you want

Tibco DX is not a good example. It hides what it’s doing and gives you no way to choose an alternative. Instead you have to hack around the tool and you end up wasting so much time that you lose any initial value you got from allowing it to do the basics.

Given the choice, I’d rather a feature poor tool that got out of the way when it was no longer useful, than a feature rich tool that locked you in and gave you no choice to do it any other way but theirs.

Rob Conery posted about why he thinks it’s important to learn MVC and I agree that it is important to learn MVC and his points are all valid. The point that’s missing though is this: So you can have an informed opinion on what the benefits are of MVC vs insert all other web technologies here.

Within MVC itself there are some interesting questions to answer like what MVC framework to use. There’s actually more than just the ASP.NET MVC framework, and even if you settle on ASP.NET MVC, you’d be wise to also evaluate the different viewengines,  the different controller conventions and the various routing styles.

If you get asked your opinion on whether MVC is going to be more suitable than WebForms for a new project you’re starting, there’s only one way you can truly answer that question with any authority and it’s from having a good understanding of what MVC offers. The best way to get that understanding is to learn it.

This holds true for pretty much any comparison. Is the Entity Framework more suitable than NHibernate? Is MSSQL server more suitable than Oracle? Are Macs more suitable than PC’s?

You can read as many articles as you want to get a general feel for what each has to offer, but the only way you’re going to get a truly valuable opinion is to roll up your sleeves and get dirty with the tools.

Even just building the most basic applications will tell you what the friction points are, what the benefits are, how this technology will require you to approach the problem and ultimately form your own opinion.

I agree with Rob, you should learn MVC, but I’m adding another reason to the list.

I’ve resisted the urge of learning a dynamic language like F# or Ruby for a while but it’s hard to ignore that the deeper you go into c# the more it gets in your way. In the last 2 days I’ve had 2 problems in c# that simply wouldn’t have existed in a dynamic language.

First problem I had was needing to assign multiple values to an object property but I wouldn’t know the type of the value until runtime. The property was an int, but I could potentially assign a decimal or a long depending on what was returned from the underlying data source. Because c# requires static typing I had no choice but to choose an int as the property type and then do a bunch of crazy casting to handle the various runtime issues. In a dynamic language, I’d just assign the values and the type would be inferred.

The second problem I had involved variance with generic collections. The situation was that I had an interface called IParcel which was implemented by  two classes, Disposal and Parcel. I also had a function that accepted as a parameter IList<IParcel>. The problem was that I couldn’t pass an IList<Disposal> or IList<Parcel> to the function even tho Disposal and Parcel derive from IParcel and therefore should be considered perfectly valid. Instead I had to call ConvertAll() on the collections to convert them to IList<IParcel> objects and then pass the converted list to the parameter. In a dynamic language, I would just pass either list into the collection and life would go on.

Variance is being addressed in c# 4.0 but it’s only one circumstance where these sorts of problems begin to hit the limit of what c# can do.

It will be interesting to see what direction Microsoft takes with C# and dynamic languages. It seems that they’re looking to accommodate dynamic typing within C# as much as possible but where pure functional programming is required they’re pushing people to F#. This makes good sense but I wonder if the lines will become blurred by allowing easier access to F# from directly within C#.

Whatever they do, I don’t think I’ll be making a full blown switch to a functional language soon but I’ll be watching what happens in this space as there is definitely room for some interesting solutions to these interesting problems.

There’s a bit of buzz around Domain Driven Design at the moment and while I haven’t gone too deep with DDD, there are certainly some aspects which have challenged the way I’ve been approaching problems.

In the past I’ve used plenty of ORM tools which are heavily dependent on the database and this reliance often results in a domain model that directly represents the database table schema. This is often a quick and convenient method of creating a data layer and it works well for the most basic of CRUD applications, however when your applications begin to get complex, this method can be left sorely wanting.

What has interested me most about DDD is the concept of a Doman Context and modeling "objects" based around a specific context. In a recent project this has worked for me in two ways.

First I had a domain context that was based around reporting, where I had data coming from a number of different tables but had to be mapped to a single object. The situation was analogous to having a business that could accept orders online, in store or by mail and each different order was stored in a separate table. I then wanted to create a sales report that showed a summary of all sales in a common format. With ORM solutions I’ve used in the past, I would have 3 objects mapped to my different tables called OnlineOrder, MailOrder and StoreOrder. I would then have had to massage that data into a common ReportOrder object and bind it to my report.

With NHibernate I was able to create a mapping for each table and map them all to the single ReportOrder object. This allowed me to have a nice clear representation of my domain model that was clearly abstracted away from my database model.

The second situation I had was where I had a single table that I needed to be represented in multiple domain contexts. For example I had a Customers table which had one-to-many relationship with an Addresses table and an Orders table. In one context I wanted to update the Addresses and in another context I wanted to validate orders. If I was using an old school ORM, I’d have a Customer object with a collection of Addresses AND a collection of Orders. I’d have to make a choice as to whether or not I wanted to lazy or eager load each collection based on what I was doing with the parent object. With NHibernate I was able to just create two seperate objects that did exactly what was required by domain context. One Customer object had a child collection of addresses whilst a seperate one had a child collection of Orders. This example is greatly simplified but being able to create multiple objects based on specific contexts has meant I’ve been able to greatly simplify my domain model and reduce the complexity of my objects.

I haven’t done enough DDD to consider myself an expert or not, but combined with NHibernate I’ve definitely been given plenty to think about when it comes to modeling my domains.

I’ve been using NHibernate as the back end for a web service and ran into a little problem when returning the NHibernate objects to clients via the web service. I had a Person object which had a child collection of Addresses which I had explicitly set to lazy load depending on the request from the client. The lazy loading was fine, however when I went to serialize the Person object the serializer would check the Address property and therefore cause a lazy load of the Address collection.

I couldn’t find a way to tell NHibernate to ignore future requests on the Address collection once the Person object had been populated so in the end I had to handle it manually and return custom DTO objects via the web service.

As yet I haven’t found a better way to deal with this situation but hopefully there will be a way to remove objects from the NHibernate session or at the very least tell NHibernate to ignore specific objects in session.

In Australia we are in the unfortunate situation where no matter where you are, you have to pay line rental for your landline phone. Then on top of that you have to pay for your phone calls. The catch was that even though I didn’t use my home phone for phone calls, I had no choice but to pay line rental because my ADSL connection relies on the phone line. Even more annoying is the fact that I have VoIP hooked up through PennyTel so even if I did use my home line, I wouldn’t be using the private carrier.

So, my monthly "Telecommuncations" bill looked like this:

• $49.95 for my internet connection through netspace (40gb Downloads)
• $29.95 line rental
• $5.00 per month contract with PennyTel (plus calls)

Which left me with a total bill of $84.90 and feeling like I wasn’t getting great value.

It was also a pain because there was 3 different bills and it was just generally a hassle.

For a while now, Australian ISP’s have been offering "Naked" ADSL plans which effectively allow you to have an ADSL connection through your phone line without paying line rental. It’s not quite how it works, because you do pay a premium for the "Naked" plans. Recently Netspace released their Naked ADSL plans and for me, it worked out being cheaper and better value than ADSL with line rental. I now just have a Netspace bill and a PennyTel bill which I like.

• $74.95 for ADSL through netspace (50gb downloads)
• $5.00 per month contract with PennyTel (plus calls)

I now have a total bill of $80 / month and it’s only a $5 / month saving, however I do get more downloads and I don’t feel like I’m paying for something I’m not even using.