Regarding MOSS or WSS 3.0, What parts of the API might have been implemented better?

只愿长相守 提交于 2019-12-03 16:15:58

I wish that the Sharepoint object model was purely managed code. Although having .NET wrappers is convenient, having to worry about disposing the many objects that implement IDisposable is a pain. It's so easy to run into memory issues when dispose does not get called in a WSS app. And I thought the reason for moving to .NET was to free developers from having to deal with memory management...

How about refactoring Properties that result in additional database calls to methods instead, for example the Items property on SPList.

Any of the SPList API could use a complete rewrite. Trying to deal with libraries with nested folders is a complete nightmare with the list being completely flattened with no obvious hierarchical structure.

Another wonderful addition would be adding interfaces to SPWeb, SPList and other Sharepoint classes to aid testing.

Has anyone seen this method: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsecurity.runwithelevatedprivileges.aspx This method shows the unbelievable nonsense that Sharepoint exposes to developers.

My personal favourite is the SPField.GetFieldValue Method. I have no idea why they designed it the way they did, but to me it does hardly make sense. To get a object out of a ListItem you have to do somethine like:

SPField field = ((SPList)list).Fields.GetField("FieldName"); 
object fieldValue = field.GetFieldValue(((SPListItem)item)[field.Title].ToString());

Getting an object out of a ListItem is IMO a basic operation, so this should not be that complicated.

Inconsistencies when passing field names to methods or arrays. For example:

To put the icing on the cake, there is usually no documentation about whether a method takes internal and/or display name.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!