Every SharePoint developer class I teach has a module on web parts. Needless to say, this is one of the most popular modules because I do a couple of killer demos, and because creating web parts is a big part of most SharePoint projects.
However, simply creating a web part is not enough. The web part must be configurable by the user – I want to ensure the user has the ability to adjust the web part for their specific needs. Once you determine the personalizable properties of the web part, the next question is what interface you want to use to accept the information. After all, there are many ways that this could be accomplished, including a custom editor, a connected web part or your own custom UI that you place on the web part itself.
Of the three listed above, my least favorite is to create a custom UI on the web part itself. The first reason for this is you’re creating a UI for an environment that already has a UI for accepting personalizable values – the web part editor itself. Additionally, the user will have been trained how to edit a web part. If I add a custom UI to the web part itself, I’m now providing exceptions to the normal rule for my users. I want my users to have a consistent experience. Nearly every other web part is configured through the editor, so I’m going to leave them there.
The next option is to create a custom editor. A custom editor allows me to inject my own UI into the normal SharePoint web part editor section. This allows me to add on validation and give the user a better experience, all while maintaining consistency at the same time. I’m a huge fan of this, and for the most part I don’t create a web part any longer that doesn’t have at least one custom editor. The SharePoint editor, and in turn the custom editors that I create, are perfect for personalizable values that will persist over time and rarely change. I call these “Set it and forget it” values – ones that will be set when the web part is added to the page and updated infrequently.
The last option for allowing the user to set a value that a web part will act upon or persist is to create connected web parts. A connected web part allows the user to place two web parts on a page, select or update a value on one and see the result on the other. Connected web parts are great for settings that need to change frequently, or providing the user the ability to interact with the data. That being said, you can achieve the same result, like a master/details view, in a single web part. In a single web part, you’re to easily take advantage of AJAX calls to avoid the round trip a connected web part will typically need. While AJAX is cool, it’s also nice to allow the user place the two connectable web parts anywhere on a page and let the user decide what form of a UI will work best for them.
As with everything in SharePoint, there is no one correct answer. The best approach is to analyze the situation, interview your users and figure out what is most appropriate for your situation. But I would say that as a basic guideline that a connected web part is best for the interactivity needed when looking for something along the lines of a master/details view, while most (if not all) other personalizable properties are best set through the SharePoint editor, preferably with your own custom interface.
 Why is it that people say “needless to say” but say it anyway?
 Although I might be biased.