Why I don’t like SharePoint: Part I
Recently I’ve been keeping myself busy developing several SharePoint solutions. One of them was more of a normal website using some of SharePoint’s most basic features (web parts mainly). The other one a full SharePoint website, customized to do everything but making dinner. I have to say that I prefer the first one above the other, but that is mainly because that one was less likely to make me jump off a bridge.
Let me make one thing perfectly clear though, out of the box, SharePoint is a very good product if you just use it as it is when you install it. But if it’s customization you want, I’m quite tempted to say that it is definitely NOT the easiest product to work with. I personally tend a lot more towards normal ASP.NET development, so this is not written as if I’m a SharePoint guru, because I’m not and never want to be one (respect for the ones that managed to). I just want to put down some of the things I’ve experienced in those projects that have made me come to dislike it so much.
Part I: Lists
Lists are the equivalent of a content database in SharePoint. All the data is stored into them. The fact that behind all of it is still a SQL database kind of makes it strange to me. Why not query the SQL database straight away? You can’t do that though because it’s so cryptic that it’s quite useless. Anyway, that isn’t a problem for me personally. If it wants to secretly save the lists to SQL, fine by me. I’ll just query the lists then.
To query the lists, you will have to use a language called CAML, which is similar to SQL but for some reason always does things a bit differently from what you’re used to in SQL. But that isn’t a problem either seeing as how it’s a pretty basic language to learn. It’s a bit weird, but usable. You might notice that I have yet to really mention something about why the list idea would be so bad. My biggest problem with the lists is the way they handle the data they should contain and the way lists themselves are handled by SharePoint.
Let’s imagine that I have a need to store some data, such as a list of products. A product has a name, so let’s make a “Name” column in our list. Oh wait, I can’t. SharePoint lists all use a name column for internal uses so you can’t use that. Other keywords like “Title” are also a no go, which strikes me as strange. The developer in me thinks that they could’ve easily given all internal columns a prefix, which would’ve effectively solved the problem.
The biggest problem I have experienced with SharePoint lists however is it’s inconsistency. Let’s say that you have a list that you want to retrieve data from using .NET code and retrieving a value in a list item’s column happens by its column name. If I were to change the column name (which can happen) you still have to use the old name, because that’s the name it was made with. On changing the column name you only change it’s display name and not its internal name. I know that when you’ve made a good object model the chances of changing a column name are small, but as far as I’m concerned it’s still a likely thing to happen if a customer has a different need during development. Strange behavior in my opinion.
One last thing before I leave this post be and continue another day is the fact that the SharePoint lists lack references. You can make a lookup column that gets its value(s) from another list, but if you were to remove the list item you referenced from that other list, you won’t be seeing an error like you normally would with foreign key constraints. The result is that you end up with a null value wherever you used said lookup field meaning that you lose data. In my opinion this shouldn’t be possible without the system at least warning you that it will also delete all references.
That’s it for now, be sure to check back soon for Part II!
Steven is een afgestudeerd Software Engineer en heeft een baan als .NET ontwikkelaar. Fan van wielrennen, doet zelf aan mountainbiken, speelt wanneer hij zin heeft op zijn gitaar en Xbox 360. Probeert met enige regelmaat te bloggen over vanalles en nog niets.
Tweet er over
Plaats op Facebook
RSS Feed
Print deze post
170x bekeken
6 reacties op “Why I don’t like SharePoint: Part I”
Ik heb iets te zeggen!
Recente reacties...
Rens: Ben het met je eens dat Kick-Ass de film van 2010 is. Gewoon bruut, onverwachts en... »
Dennis Laumen: Wegens een schreeuw om aandacht zal ik dan ook nog maar even een reactie... »
Oppie: As usual I’m in agreement, except in the case of games; I do think 3D can... »
Oppie: Allereerst; bedankt voor de plug. :) Ten tweede, laat me niet beginnen over... »
Categorieën
As you know, I agree with this very much – and you didn’t even mention the great differences between the Dutch and English installation that makes creating webparts that work correctly on both versions quite impossible.
I can’t wait for part 2 so I can agree to that one too!
Sounds like you want to do some more SharePoint development
Ow btw i think the nearest bridge is either in Hoensbroek over the highway or in Maastricht over the river Maas.
Nah just kiddin, just talk to our SharePoint boss im sure he will listen…
..everything has a reason, if you look at the API.
You could get Field using GUID too.
Think about scenarios where you have a C# code in your web part to display details where you are getting a field called “Product” based on which your entire code does some rendering. You deploy the solution for the customer. Now you have user using your wondrful web part but at same time you have contribute users who feel the need to call field name something else (let’s say Business_Prod) Now if display name was always used to retrieve Field then your C# would have failed.
I do understand there are lot of grips about SharePoint i myself have a list of them.. but not this 2nd part, Share point list never maintains referential integrity between 2 lists. If you need to do that, you need to write custom even receiver like you have to write Triggers in Database.
I’m sure the SharePoint team made all these choices for a good reason, what I’m trying to note here is that as a developer that isn’t specifically trained in SharePoint some of these choices strike me as odd.
Why would you choose not to have a form of referential integrity in your lists?
In my opinion having a different internal and display name just adds unnecessary overhead to your C#/VB.NET code. If I were to give a piece of code that has some columns referencing to an internal name to another developer he would probably search for hours to eventually find out that he’s been searching for the wrong name. I can imagine the code becoming a mess when you are constantly using internal names that you can’t find in SharePoint because they’ve been renamed.
Also, as Oppie noted, if I would want to retrieve the (reserved!) “Name” field, I need to make different code for an English or a Dutch installation. Retrieving the “Name” column simply won’t work in the Dutch version. It’s strange to me that what you could call the data layer in SharePoint is language dependant.
Isn’t that at least somewhat weird?
I also don’t get the people who just implemrnt too many functionality into sharepoint.
The break even point for just making a custom (web)application is reached much sooner then everybody thinks. When implemented, I think the custom application has a great advantage. It is just easier to add/change new (complex/not sharepoint standard) functionality.
Also the fantastic sharepoint websites can suck the life out of any server. THAT’S WHAT YOU DON’T WANT!
1) It stores and consumes bits and bytes were even (Lord) Bill Gates didn’t find them yet!
2) For some weird reason it performs like shit, maybe it has something to do with those bits and bytes.
Actually the people who want sharepoint as a functionality aren’t stupid, all together with MS Dynamics. But all those tools in Dynamics and sharepoint etc just won’t work perfectly together plug and play. And maintenance is expansive, because you have to train someone at age of 5. Never teach the child math. Teach him to write an _UnderScore_ before every word.
Sharepoint Olé!
I was happy when we gave up and switched from MOSS to a regular ASP.NET development. That huge attempt to make all-in-one machine failed as usual. Absolutely inflexible and inconvenient.
Here’s our MOSS story:
http://pro-thoughts.blogspot.com/2008/01/why-i-hate-ms-sharepoint.html