You can use the Effects for Direct3D 11 library (aka FX11), but should keep in mind that the HLSL compiler support for is deprecated, support for it exists "as is" (i.e. there are some known bugs in the fx_5_0
profile that will not get fixed), and may be removed in a future update. You should use the GitHub version of the runtime library as it has a number of fixes that are not present in the legacy DirectX SDK version.
As to your original question, here's some info from the soon to be defunct CodePlex: What's the difference between an .fx and .hlsl file anyhow?
Historically the extension '.fx' refers to a HLSL shader intended to
be built using the legacy effects fx_4_0, fx_5_0, etc. profiles; while
'.hlsl' refers to individual HLSL shaders. The reality is that there's
no consistency here. You will see lots of '.fx' files without any
technique/pass statements.
Unlike C/C++ source files, HLSL files can contain a lot of stuff that
gets ignored in a given invocation of the compiler. If you have a big
.fx file with a dozen shaders in it and a bunch of technique/passes,
you can compile the same file many times with different entry-points
and profiles to generate lots of shaders.
It's really all a matter of how you want to build your shader content.
For example, DirectX Tool Kit uses a command-line script to build all
the possible combinations of shaders: currrently it builds 86 shader
blobs from 7 .fx files (and actually it can build them twice: once
with the Windows compiler and once with the Xbox One XDK compiler, but
only one set of these shader blobs is included in a given build of the
DirectXTK.lib anyhow).
If you use the Visual Studio 2012/2013 content pipeline to build your
shaders, you do have to deal with a limitation of MSBuild which
assumes each source file is built once for each result. So in that
case, you'd want an individual '.hlsl' file for each shader
combination (which for the DirectX Tool Kit example would mean 86
'.hlsl' files). One way to handle this would be to keep the shader
source itself in a single file, and then have a bunch of .hlsl files
that #include the 'source' file. Something like:
BasicEffectVSBasicVertexLighting.hlsl
#include "BasicEffect.fx"
BasicEffectPSBasicVertexLighting.hlsl
#include "BasicEffect.fx"
You then compile each of these .hlsl files once with the proper shader profile and entry-point. This approach
works fine for smaller projects, but doesn't scale well to large
complex shaders without using legacy fx profiles. In that case, other
build solutions like DirectX Tool Kit's build solution is probably
better.
If you are using legacy fx profiles, you of course only have to
compile each .fx once and it will generate all the shaders it
specifies in technique/passes in one go.
Frank Luna's Direct3D 11 book is a victim of its timing. It was published just prior to the legacy DirectX SDK being deprecated. The basics of the book are great, but FX11, D3DX11, and XNAMath all have replacements that avoid using the legacy DirectX SDK. See Living without D3DX, Introducing DirectXMath, and Book Recommendations.
UPDATE: While it's still strongly recommended that you not use D3DX9, D3DX10, or D3DX11 in new projects, for tutorials or books like Luna's that assume you have the legacy DirectX SDK installed, there's now an easier-to-use solution for modern toolsets: use the NuGet package Microsoft.DXSDK.D3DX. See this blog post for details.
Effects was always an optional system which made it easier to bind a group of related shaders and state based on a file format. You don't need Effects, and you can always compile the fx
file multiple times for each permutation of the individual shaders and handle setting up all the related state yourself.
If you are new to Direct3D 11 development, you should take a look at DirectX Tool Kit and it's tutorials as it provides a number of 'stock' shaders which can get you a long way.