Going from .NET to Drupal? Here Are the Top 5 Ways They Are Different

June 12, 2015

Drupal is an incredibly flexible and expressive CMS and development framework. As a
developer, it allows you to express yourself quickly and easily. That being said, being able to do anything​ can be a little overwhelming.

Switching from .NET to Drupal 7 isn’t easy for most people. They take fundamentally different
approaches to development that aren’t called out. There is also a surprising lack of articles and documentation on the subject. Two years ago I made the change to Drupal. I didn’t have
anyone to help, so the transition was harsh. Developers not only struggle with the transition, but
more importantly with the ability to adopt best practices. The end result is often unstable, and

This is the first post in a series highlighting the differences between .NET and Drupal. The goal
is to help you as a developer map concepts from .NET to Drupal and give you the foundation
you need to be successful with Drupal. You’ll see that Drupal development is actually easy,
robust, and a lot of fun.

Here are the top 5 ways that Drupal and .NET are different:

Framework Support

Drupal is a CMS but it’s also a development framework. Where .NET has an API for everything,
Drupal has a lean core API, and a large ecosystem of open-source modules to provide extra
functionality. This is where Drupal’s CMS background shines. Drupal has fully completed
modules designed to meet business needs. There is a module for everything: modules for
styling content on a page, displaying social content, and even translation. I cannot stress this
point enough. There is a rich open source community in your corner backing you up. Modules
keep you from reinventing the wheel and allow you to dramatically increase your development

While you have a clear API to follow with .NET or Java, Drupal requires a certain amount of
tribal knowledge to build a real site. You need to be able to know which module meets your
needs. It’s overwhelming at first. Here you are struggling to figure out Drupal core and at the
same time, you have to figure out all these modules as well. It takes time, but eventually you
start to get a feel for some of the basic modules to start with. (I recommend checking out
Lightning​ for a curated list that we use here at Acquia. And posts ​on identifying​, ​searching,​ and evaluating​​ Drupal modules).

Different Approaches: OO vs. Procedural

In order to understand the chasm between .NET and Drupal it helps to understand the
background and differences between C# and PHP.

C# is a descendant of C, C++, and Java. As such, C# has been around for a while and has a
mature object model. PHP only added modern OO capabilities in PHP 5.0 (2005) and late static
binding in PHP 5.3 (2009). PHP is a relative newcomer to the OO world.

The difference strongly influences code structure and coding practices in Drupal 7. A lot of PHP
code in D7 is largely procedural. Some of the newer PHP code is OO but in D7 that’s the
exception rather than the rule. This means that functions are not grouped together in small or
medium understandable objects, or even namespaces. Most functions are defined in a global
scope. Procedural code lacks the structure and aesthetic of OO code.

In an object-oriented world, a clear hierarchy of objects guides your development. When you are
working in Java or ASP.NET, that object hierarchy can be reassuring. You can turn to it to tell
you what to do. It is also listed in the API documentation, and you can drill down through it to
understand what you need to do to effect change.

You can also always look at the object in a debugger to see all the methods and properties
supported. The lack of object inheritance in procedural code makes it difficult to follow code and
understand what is happening. In a procedural language you need to simply know the functions
that are available to you. Since most functions are defined in global scope, they can be

Strong vs. Loose Typing

The other major difference is that C# is a strongly typed language and PHP is a loosely typed
language. In strongly typed languages, such as C#, variables are declared with a type. In
loosely typed languages, no type is required.

string myVar = “This is a strongly typed declaration”;

$my_var = “This is a loosely typed declaration”;

One has a type and one doesn’t. So what’s the big deal? By looking at a variable declaration in
C# you immediately know that it is storing a string. On the other hand, in PHP, you can only
infer based on the right side of the declaration statement.

Here is a great example of the confusion this can lead to:

$my_var =  node_load(123456);

What is the type of ​my_var​? Without knowing what ​node_load​ returns you have no idea. ​ ​This
is represents a huge barrier to reading and understanding PHP code. I cannot stress this
enough. Loose typing along with the fact that functions are defined in global scope means
reading PHP code requires a much broader understanding than C#.

Why Is Everything an Array?

The combination of procedural code, lack of an object model, and loosely typing means that
Drupal/PHP has to get creative when passing around bundles of information. It does this by
creating infinitely nested ​dynamic arrays​. Theses are incredibly powerful, flexible, and are core
to Drupal’s ability to be customized to meet almost any need.

That being said, Drupal arrays can be hard to understand and follow. They are also largely
undocumented and undocumentable. For a more in depth explanation see John Alban’s post on
Drupal 7 and the Arrays of Doom​.

So how do you work with these arrays? Most developers will either print them using the ​Devel
module’s dpm
​ or by using a PHP debug tool, such as ​PHPStorm​. I’ll discuss both approaches
more in depth in a later post. By poking around inside these structures you start to understand
what’s going on and how to enact changes!

Code vs. Configuration

In Drupal, the distinction between code and config can be ambiguous. Since .NET is a
framework not a CMS, there a clear line of demarcation between what is code and what is
config stored in a database. In general items stored in the database represent content/user

Drupal, on the other hand, is a CMS, one that is extremely customizable via the user interface.
We call this​ site-building. ​In Drupal, you can build a new content type just as easily as you can
create a new article. This flexibility and configurability are one of Drupal’s strengths. However,
from a developer’s point of view, this makes things confusing. When do you need to write code?
When do you need to do things via the GUI? The line between code and config is extremely
blurry and often debated among Drupalistas. (We’ll cover this more in a later segment.)

Till Next time

No doubt, Drupal comes with its fair share of challenges, a few of which we just talked about.
But those challenges are not insurmountable. At the end of the day, the things that can make
Drupal tricky also contribute to its flexibility and power. These attributes have positioned Drupal
as a CMS leader. I hope that mapping concepts from .NET to Drupal in this blog series will help
make the transition smoother and easier for you.

In future blog posts, I’ll go into depth on some of the more granular elements of Drupal, such as
working with hooks, modules, and Drupal core. Stay tuned.

Sign-up for our Developer Blog Newsletter


Add comment