Earlier this year I spoke at the Southern Fried DotNetNuke event and one of the most popular of my talks was "Developing Enterprise Solutions with DotNetNuke." Now that we have one of the final hurdles cleared from an implementation perspective in this post, and future ones I will start to share all of the details that I have been promising. This post will serve as a launch point for the future parts, as of this point in time I believe this will span 8-10 posts to give everything the proper coverage necessary. As the series grows I will update this post with links to the future sections. So let us get to it!
The following high-level items will give a glimpse into the goals, terminology, and practices that I am lumping into the category of "Enterprise Extension Development.". I truly hate the term Enterprise as it is a very misleading term and is often interpreted to mean different things in different contexts but it is the most appropriate subject for this series.
What is "Enterprise Extension Development"
If we look at the dictionary definition of Enterprise we will find the following:a project is undertaken or to be undertaken, especially one that is important or difficult or that requires boldness or energy. This formal definition is actually a close representation to the types of project that I'm lumping into the category of Enterprise Extension Development. These might be projects that combine Modules, Providers, Skin Objects, Dashboard Controls, or any other of the extension types available in DotNetNuke. It might include a project that is single modules but has requirements for Unit Testing or support of Automated Builds. In addition to these types of options, it will often include situations were shared libraries or communication from extension-to-extension might be needed.
It is all of these situations specifically that will be addressed as part of this series. However, you will often find many of the enhancements discussed here in ALL of my DotNetNuke projects as I find that consistency in these processes makes for a much easier future path for all modules large and small.
How Is Enterprise Development Different?
So now that we know what I define as "Enterprise", why is it different? What attributes of these project types dictate a different approach than what you might have had in the past? The true answer to this is multifaceted but can be summarized into a few key categories.
Differing Expectations
Often, larger or more complex projects are going to set different expectations than those one-off modules that you just whip together and get out the door. For example in a situation where you have multiple modules that work in concert with each other the communication between each part should be seamless. Additionally on these larger, more complex, projects there is typically an expectation of quick support and easy expansion for future growth needs. To support this it is important to start with a solid foundation so you don't have to do a bunch of cleanup once the project grows beyond the initial scale.
Scale/Scope of Implementation
As projects get larger, it is often the case that the implementation scope is going to be larger. Having an infrastructure that allows for easy internal code-reuse and a consistent way to incorporate third-party libraries will be an integral part of any Enterprise solution. This typically pushes the limits of the existing templates and guidance as neither of these topics are discussed in the documentation.
Team Development
With larger projects is if often a situation where more than one developer will be working on a solution at a time. As such it will be important to take a look at the development process to see how teams can work in conjunction to quickly and easily work on larger projects together while still maintaining autonomy to get their tasks done without stepping on the rest of the team. Another key item is ensuring that there isn't a complicated setup needed for new team members to jump in and get their feet wet on a new project!
Standards & Future Proofing
The final area that is often different for Enterprise development within the DotNetNuke platform would be standards and upgrades. When working with an Enterprise solution it is important to take standards seriously and really focus on making sure that you are doing things in a manner that will allow your solution to grow with DotNetNuke, so you can easily migrate forward as the platform evolves. Items in this area include UI standards as well as standards of integration to ensure that you are not boxed into a situation.
Learning Areas
Now that I've gotten a bit of the overview information about WHY we are concerned about this topic I am going to move into what will be covered in this series at a high level. The future parts of this series will be broken out into 5 key areas and at least 4-6 additional posts to cover all of these items properly. The following sub-sections outline these learning areas/topic.
Development Model and Structure
For these posts we will focus on the WAY that we develop our DotNetNuke solutions. For example the individual setup of a developer machine, the way our projects are structured in relation to a DotNetNuke installation, and the way that packaging. Key considerations in this area will include the streamlining of MSBUILD processes for those items that are necessary for Enterprise solutions. How to structure your solutions so that NO setup is necessary on a workstation to start work, simply have a machine with Visual Studio and do a Get Latest from your source control system of choice and start developing!
Project Structures & Locations
Once we know what the code environment looks like at a high level we will dive into the specifics of solution structure and how things will be deployed to DotNetNuke. Key concepts in this area include how to handle Multi-Project solutions. Integration and deployment of third-party libraries, sharing code between projects, and DotNetNuke installation structures.
Developer Efficiency
A good structure for Enterprise development might lend itself to be "less fast" by default from the models that are currently documented. Once the basic project structures have been outlined we will look at tools and DotNetNuke options to help improve efficiency while maintaining a solid structure for our solutions and projects.
Testing & Automated Builds
One side-effect of following the recommendations that I have for project and development environment setup is that solutions will be fully set up to allow for easy integration of Unit Tests and even support for Automated Build processes. We will discuss first the process of creating a good testing plan for DotNetNuke installations and the actual usage of your extensions. Then after ensuring that we have a good product at that level we will discuss how Automated Builds and Unit Testing can give peace of mind when it comes to ensuring that what was working stays working!
Best Practices & Being a Good DotNetNuke Citizen
The final section of this series will discuss best practices recommendations and a topic that I call "Being a Good DotNetNuke Citizen." What is meant by this is how can we develop solutions in a way that is "proper" for the way that DotNetNuke works so that we as developers can do our job quickly, integrate fully with DotNetNuke and still maintain a level of protection from issues with future releases of DotNetNuke. This includes methods to re-use components from the core and others.
Feedback and Other Areas of Discussion
Content for the future posts has already been partially written so I anticipate 1-2 posts per week in the coming weeks to get all of this information out there. However, if you have an idea of an area that I should expand into please feel free to share it in the comments below.
This post was cross-posted to my DotNetNuke.com blog.