You probably don't need to, but that doesnt mean you should never.
There is a lot of advice, around the internet, and in the top rated post on this page, telling you that you "Must Not" dispose the DB Context.
The logic here is fundamentally flawed. This is a bold statement, so let me explain.
There is a difference between "You don't need to do X" and "You must never do X".
If you create the context, then let the garbage collector take care of it at some undefined time in the future, you aren't going to get memory leaks. This means, essentially, that you "Don't need" to dispose of the context explicitly.
However, this does not logically translate into "Must Never".
If you read the actual MSDN documentation for DbContext you will see that there is a benefit to explicitly disposing the context; it has many resources that it holds, including caches.
Use using if you want all the resources that the context controls to be disposed at the end of the block. When you use using, the compiler automatically creates a try/finally block and calls dispose in the finally block.
If the context is created in application code, remember to dispose of the context when it is no longer required.
Leaving the task of disposing that stuff to the garbage collector will slightly increase memory usage - of course, you "Might Not" ever encounter that problem, and will be able to ignore it.
The automatic internal disposal seems to be a safety measure only
Applications doing huge volumes of DB access using a DbContext will have interesting memory usage patterns. Having an understanding of the various modes of garbage collection is important here.
In particular, you need to understand what happens when you hit what Microsoft refer to as "High Memory Usage Percent".
when the physical memory load reaches 90%, garbage collection becomes more aggressive about doing full, compacting garbage collections to avoid paging
This is when the large amount of cached data that you find in as yet undisposed DB context begins to be an issue.
Many of Microsoft's own examples of EF usage literally tell you to dispose explicitly
For example, here is a microsoft tutorial (for EF5) of the implementation of a repository.
The code sample here explicitly disposes the context when the repo is disposed.
Make a decision based on the facts
The DbContext is intended to act as a single "unit of work". Its unfortunate that Microsoft chose to hide the fact that they are implementing the unit of work pattern - I believe that's what has led to this confusion.
If your services are doing things like, processing huge volumes of data, you will find that the undisposed resources maintained internally by your DbContext will push you into "high memory percentage" territory. At that point, its worth seeing if explicitly disposing of your DbContext makes a difference. You as the developer know that those resources are no longer needed, whereas the garbage collector does not. That isn't its fault - its a general purpose tool.