So, my good SharePoint buddy Nik Patel (@nikxpatel)tweeted this question to me while I was driving one day [see image below for the feed] and I must admit, he isn't the only one to ask it. It seems and rightfully so, if SharePoint is built on .NET and its Object Model is a subset of .NET why not just create your own objects for data source, modeling, and presentation when trying to surface data in SharePoint?
Framing the discussion
If you know me, you know I am passionate about Microsoft SharePoint, moreover, I am very passionate about previously MOSS BDC, and now what is SharePoint 2010 Business Connectivity Services (BCS), if you have ever seen me speak, you know just how animated I get while presenting on the topic. Not only that, if you have read my blogs, you know although I am excited about what Microsoft SharePoint Designer 2010 (SPD 2010) has done for BCS; the ability to surface data with No-Code Solutions, you also know, I think it is just a good start, and if you intend to do anything above "Departmental Level Work"… you need to crack the seal of Visual Studio 2010 for that.
<caveat> Unless you are consuming a ECT in SPD 2010 that was created by a professional developer in Visual Studio and is in the Metadata Store just waiting for you </caveat>
With all of that out of the way, and my bias of being a SharePoint Dev, I will say if I was wearing the hat of a pure ASP.NET developer that I agree totally with Nik, but wearing the hat of a SharePoint [ASP.NET] Developer, I would have to say that the answer is not that simple. I have often pointed out and usually when answering this question that an ASP.NET developer is not the same thing as a SharePoint Developer, and not that one is better than the other, they are just different. While a SharePoint Developer that just understands SharePoint in the auspice of .NET is limited to that knowledge in only as so far as .NET has to offer, he/she is specialized; and while a .NET developer who has learned SharePoint has a lot he/she can bring to the table with additional underlying knowledge, managing or maintaining discipline can be a challenge in terms of when to turn it on and turn it off. I am pleased to admit, I am a happy mix… I converted to C# just about the same time I was learning SharePoint, so I have a fundamental background in OOP, but I was new to C#, and in learning C#, my emphasis was on SharePoint.
Personally, yes I lead with personally because this is just my opinion, I would argue that one should use the Templates and Modeling Provided in Visual Studio 2010 for BCS over creating your own Object, Methods, Events for surfacing External Data in SharePoint, and here is the reason why…
- Less Clutter and More Abstraction
- Closer Code Alignment with the SDLC of the Vendor (Microsoft)
- More Support Options from the Vendor and Better Adoption from folks who have to Maintain your Code and Support it moving forward
I think that those three points are at a high level what I believe are the compelling reasons for using BCS over standard .NET with your own Connectivity and Presentation. I can certainly dive deep into each one of those layers by addressing PASSME which if you studied for your MCSD you are intimately familiar with but for those who didn't…
P – Performance
A – Accessibility
S – Security
S – Scalability
M – Maintainability
E – Extensibility
These are philosophies that I subscribe to whenever I am faced with a decision of coming up with a solution for a client, moreover, although it is a challenge, I train myself to think… "What can I do Out-Of-Box First!" and yes, that is hard when you are a Dev.
However, let me address this from Niks' position, and no… I am not picking on him, Im just using his argument to make my point academically J
Using ADO.NET, Linq-To-SQL [or Linq-To-Anything], Entity Framework to access SQL Data
Yes, that would work, absolutely it will, but what is the investment that you will have to do to get there? What is your responsibility for the code you write thereafter? As a Dev, you are usually playing the blame game when it comes to troubleshooting/ maintaining/ debugging. I find it is easier to use Object/Methods/Interfaces that are created for me by the vendor and use API calls to manage the ins and outs because I trust the abstraction that is given to me and hey… I am only responsible for what comes out of it and how I use it. Now, one would argue that you have more flexibility if you own it, and yes that is true, but guess what… you now own everything. Plus, lets take the ego out of it… from a client standpoint, if you adopt that model, now you have to write that much more in your Design/Implementation/Support Document [and yeah.. you are charging for that], and when you are handing off the project, the requirements that you are putting on the client is so much more than if you took another approach.
Additionally, when working with SharePoint and surfacing External Data, security is key, right? No one wants to have their important data, proprietary data, just out there. By plugging into the BCS and SharePoint you can further take advantage of the layers of security provided, lend consideration to the fact that…
OOB Support for:
- Windows Authentication
- Forms Based Authentication
- Claims based Authentication
- Revert-to-Self (process account)
- Pass-through (logged on user)
- Single Sign On (Secure Store)
Secure Store Service
- Can store windows credentials or non-windows credentials
- A credentials page available to gather credentials from a user & store it in SSS
- Extensibility to plug in another SSO
Wrap it in a WebPart and Present in SharePoint
Yes, you can do that too, and guess what, you can still do that with ECT's coming from BCS if presentation is your only concern. Not only that, but that ECT that you created can be consumed by everyone with the right access, and they can use it in ways that not even you imagined, thus providing more benefit to the organization.
I think Nik hit some good points, and usually I am debating this with other folks also, but because I know Nik, and I told him I was going to blog the response, and this will probably make it in a Chapter in my soon to be published book on BCS, I figured id get some dialog going. I think in the last tweet Nik also pointed out some other intrinsic values to doing it with BCS
- Platform Integration
Search being the biggest winner, because ECT's can be set to be Crawlable, and now you have a solution that… again is extensible.
So, I know I could have gone deep in the PASSME, and I intend to do that in my chapters, but for now this is what I have for you… hope this helps when faced with that decision, and when im asked again, trust me, Ill be pointing you to this blog.
Cheers and Happy SharePointing