SharePoint 2010 - Best practices: how to handle assemblies [Discussion]

Question

There is a discussion which has been going on for serveral years when programming for SharePoint.

In Visual Studio you can add a SharePoint solution, which will be converted to a .wsp file to deploy. This .wsp file will contain all required assembly files.

How do you guys hande the codebehind files for: Event receiver, feature receiver, aspx page ?

Do you place this .cs file inside your SharePoint folder? (this way you will need to deploy a .dll from you SharePoint project aswell)

Or do you move all the code logic to one (or more) different project(s) (class libraries) ?

What you do for example in the second example:

• Right click, Add New item, Event Receiver
• Move the .cs file to a different project
• Change the assembly information inside the Elements.xml file

In the first example we do not move these files, just keep them as VS2010 adds them.

I am NOT saying which way i prefer, I just want to receive alot of input. Dont just say "option 2 is bad." I realy would like to know why and why not !

Thanks

EDIT:

My question here has nothing to do with extensions etc.

I am talking about making sure your sharepoint solution does NOT contain ANY .cs file. This way there does not have to be an assembly in the GAC for this solution.

Example: I have Customer.SPS.Intranet.Solution (=the solution to generate WSP, so an Empty SharePoint Project Item).

If I simply add a feature and a feature receiver, a .cs file is generated and (after deployment) a Customer.SPS.Intranet.Solution.dll file is placed inside the global assembly cache.

This is what some people do not want to have !!! (I do not understand why, that's why I am asking some opinions).

To solve this, they create a project inside this solution named: "Customer.SPS.Intranet.Logic", this solution will contain all the feature receiver codebehind files.

This means we have to edit the feature template.xml file to use the receiver class located in the "Logic" project. This way we keep the "Customer.SPS.Intranet.Solution" clean and we'll only use it for packaging. So there WILL NOT be an assembly deployed to the GAC named "Customer.SPS.Intranet.Solution.dll"... instead a Customer.SPS.Intranet.Logic.dll assembly is deployed to the GAC.

Answer 1

Aaah, the eternal question of solutions and dll's. :-) Why split up, why not, and when to? I'm not working atm, I'm on holiday, but as you asked me to take a look, I'll just sum up a few take away's and my take on it. So my answer is based on personal experience and view. (sorry StackExhange)

x  Not splitting up "code behind" and UI leads to code hard to maintain. Something I saw on different projects is that inexperienced developers do not cope well with "code behind" (C# classes next to XML/ASPX) They tend to write more logic into the code behind as they have direct access to the UI. On one particular project I saw a "new" page of 1500 lines (which is already huge) and the "edit" page was basically a copy-and-paste of the new page.  Sure this is"bad programming",  it is not inherent to putting code behind next to the artifacts. But bad habits are hard to change and this model of working can help make things worse. In this case making the cs class first as a control and having some kind of inherited class for the edit class, would have been more easy to maintain. Once created, you could make your asps pages inherit from these classes.

x Not splitting up "code behind" and UI leads to classes with way too much logic. Another thing on that project is that both the new page as the edit page had direct connections to external SQL databases. They used direct SQL connections which created an overhead in code and maintenance. A layered approach would have helped greatly. 

x A layered application needs separate assemblies. Well, layering is good! Do you need a separate assembly for it? Not necessarily. You can group your logic, data acces layer etc in separate folders/namespaces within your assembly. Those are layers as well.  "But why should I split them up?" It tends to be good practice. Why? Well you avoid the accidental use of more deeper logic (eg SQL connections), as that logic is only referenced in a DA layer. Another advantage is that it is potentially easier to replace the top layers by another layer. Say another user interface or a mobile interface.  You can push it even further and make lower layers more generic, so you can re use them later on. That's how nHibernate and EF frameworks can be created.

x "That's nice, but that's just ASP.NET development." Right, but the same principles and ideas can be used when developing SharePoint artifacts, like receivers. Why not work your way to generic receivers that can be parametrized with feature properties or folder properties? Reusing logic mostly results in more stable solutions.

x Separating encourages (unit)testing. Once you begin separating and creating more generic class and so on, it's not a long stretch anymore to using interfaces and models. This means that unit testing will be more easy to implement (although we should actually use TDD), as we can mock more easily. Look at the MVC framework and how things there are nicely separated. This works also for SharePoint. 

So to summarize my 2c (and a change ;-)),  you can use code behind directly tide to your artifact, but I prefer not. I rather go for reuse, generic and testable code, than having automatic matching receivers and code to artifacts (although you don't need to change the feature template XML in the manual case, as you just add the feature receiver in the properties) and easiness to locate (I use the instant Go To of VS2010) But in the end it's all about what you and your project prefer. :-)

Answer 2

Actually, personally, never encountered a solution where files from a SharePoint solution have been moved outside of a project, except maybe for situations where you have identified reusable pieces: e.g. Extension methods, Base Event Handler code. There is also a reason to NOT move it out, e.g. usually VS 2010 uses the GUiD with which classes are decorated for internal working on it connects the handler, so it could build up dependencies correctly. Also, all binaries, are anyway built in, therefore code-beside (no more code-behind in SP2010) is build-in already. Besides registering SafeControls (web parts, custom controls, etc.) would not be properly registered as Visual Studio could include external assemblies into your package, but he wouldn't necessarily scout those assemblies for the actual code - you would need to do all that manually - bad for productivity.

These are initial reflections, might come back with some more, but the bottom rule: You are not reusing those pieces - then better leave them where VS proposes to. Rather plan ahead what kind of functionality you deploy, what dependencies you have, feature scopes, activation order, etc.

Hope it helps, C:\Marius