Okay so this is
something I picked up from a recent developer group thingy and have been
annoying my colleagues about this since then.
Instead of
thinking Sitecore as one project (MVC) solution why not treat it like a
module/deliverable based implementation.
I have created a
sample solution which is here: https://bitbucket.org/ali_nahid/sckitchensync
The idea is pretty
simple (Just like DDD pattern):
You get a rough
idea of the entire implementation like what are the deliverable,
functionalities etc etc and group them. Then just like the way you plan
renderings on your page you plan bunch of different modules to implement in your
solution.
In my case I
divided my sitecore implementation into the following modules:
1.
The
core:
This module
contains the layouts and core renderings. In my case
1 standard layout
that just defines the top level placeholders. Like header, footer, content
etc.
And a
“_MainContent” rendering that defines the other placeholders like bodycontent,
bannerimage
And obviously the
header, footer type of things that are going to be pretty much same throughout
the entire site.
I’d give this task
to “Gru” the evil genius.
2.
The
Meta:
This module only
handles the meta content (google meta, facebook meta, perhaps some GA code etc)
of the site.
Let’s say “donny”
the minion does it.
3.
The
Navigation:
This module
handles anything to do with site navigation like top navigation menu,
breadcrumb, footer menu etc.
Let’s say “dave”
the minion does it.
4.
The
Imagery:
This module
handles thing like “Banner”, Background, Carousel etc.
Let’s say “carl”
the one eyed minion does it.
Each of these
modules deal with their own set of sitecore renderings.
Interesting thing about this approach is
these modules are MVC projects of its own. Sitecore is not restricting you from
doing so. Who said only one MVC
project for one sitecore website?
Ofcourse the
"Domain POCOs" and "Service" and "Repository" layer concept exists as it is. And
you can either separate them as per module or have them in their own projects is
a personal preference.
Visualizing
the above description:
instead of
doing this:
We do this:
The few
pros about this approach I could think of are:
1.
It can be very
efficient in doing something like the following:
So
you deliver a basic site with “Core, Navigation” module. Then you install/put
“Imagery” Module. Then “The fancy” looking landing page module. And so
on. Each of these deliverable are
independent to each other. So very less chance of breaking one while delivering
the new feature because they’re all separate set of dlls.
2. Easy to
distribute work:
As per description each minion can
take care of and be responsible for each module. This can come in handy to track
progress.
3.
Once done
maintaining becomes easier:
Because if something goes wrong or
some changes required to make to the, for example Imagery module, you only look
into “KitchenSync.Imagery.MVC” project as opposed to be bombarded by a massive
MVC project.
4.
Creates a
repository of re-usable components/modules. So there can be “Oakton sitecore
repository” where you can search and download a module.
For example you need a navigation
on your project download the navigation module from the repository.. you
probably will need to made the tweak in the cshtml file to match the markup but
the logic of how the navigation work remains the same. As a result you
save yourself from creating bunch of sitecore renderings and
classes.
5.
If gets follow
through then this approach enforces a consistent culture of naming convention,
field definition etc.
For example, on a page there’re
often commonly 2 fields that exists. A summary and a description. Some calls it
Short Description, Long Description and some calls it Summary and Description.
Why not agree to one. They both mean the same.
6.
Testing is
easier too. As you are testing one module at a time.
If you’re worried
about how you launch it with IIS if there’re multiple MVC projects in the
implementation, that’s not an issue either. So this is what I have
done:
I have a typical
sitecore installation which my IIS is pointing to and I am treating it as
publish directory. My build settings puts the dlls to the publish directory /bin
location so they become available to sitecore.
Then a simple
powershell script copies the views to the publish directory’s Views accordingly.
This script can be hooked to a VS post publish (I still don’t know how to do
it)
Demo Video : https://youtu.be/rvhG8BQ6sPs
So
what you think? Worth it not Worth it?
Comments
Post a Comment