4

I am starting to do a lot of sharepoint development lately, and some of the things that I have done and I dont like is to use sharepoint designer directly for things like pagelayouts, lists definitions, master pages, etc. From my point of view I think its more organized to do everything in Visual Studio. In that way you can connect each solution to a source control database and deploy/retract/upgrade easier with scripts.

My idea is to create a vs solution like this: 1. One for list and content type defintions. 2. One for webparts. 3. One for branding

but maybe this approach has any disadvantage, what other approaches are you using?

Eric Alexander
  • 43,293
  • 10
  • 53
  • 93
Luis Valencia
  • 5,201
  • 22
  • 118
  • 219

3 Answers3

4

Organizing your SharePoint development is pretty much up to you as a developer, unless of course your company has some guidelines.

What I tend to do when starting on a new SharePoint project, is that I split things up in 3 solutions.

  1. Functionality: Features, Webparts, List Definitions, Custom Actions, EventReceivers
  2. Branding: CSS, Javascript/jQuery, AJAX, XSLT, Pagelayouts, Masterpages, Site Definitions.
  3. Managers: Webservice, Integrations, Profile managers, Email managers, Group managers, EventLogging etc.

Keeping things split up in these 3 solutions gives me the perfect overview that I find soothing and I always know where to find specific things.

But I must say that I spend a great amount of time in SharePoint Designer as well, for creating or modifying the pagelayouts at least. SharePoint Designer is the best tool to insert static Webparts into pagelayouts or even inserting Webpart zones where it's needed. I also use SharePoint Designer to create lists. The interface, I think, makes it faster to work with lists and create workflows. But that's just me :)
I variate a lot between VS and SPD, depending on which part of the project I'm working on.

2

I mostly implement a Domain Driven Design in my projects, depends on the size. So the base of my projects is build of some normal class library projects.

  • Project.Core => Implements Core functionallity like Logging etc. pp
  • Project.Repository => Implements the repositories. Mosttime I use some of them, one for each kind of data connection.

Then I split my subprojects into multiple Projects too. For example a Project named "Example" ;-) - Project.Example => A SP Project implements all definitions for list and the UI. - Project.Example.Models => All the Entities - Project.Example.Repository => The Repository for the project - Project.Example.Services => Implements the business logic.

So with this kind of architecture I have a very clean one. I know where I can find each class for each kind of action and I can keep my view clean from business logic. One other thing is to break down dependencies. So not every project needs all the other references. This architecture sometimes called "Onion architecture".

At the end I package all my core assemblies like the repository and the core into an other SharePoint Project to deploy them easily to the GAC.

At the moment I am working for a big project and my developers are putting all the stuff in one or two projects. So with every release all the other releases crashes too... its terrible. :D

Best regards

Jan

Smokefoot
  • 310
  • 2
  • 11
2

In quite a few of my client's development projects, we work with mapped folders and Visual Studio 2010. The procedure is described in Chapter 3 of 'Inside SharePoint' and also here - SharePoint Developer Tools in Visual Studio 2010.

I would also suggest Patterns & Practices documentation on 'Developing Applications for SharePoint 2010' to construct better application solutions.

Supriyo SB Chatterjee
  • 2,911
  • 14
  • 22