忍不住了，今天必须抱怨一下

Sharepoint 这个肥胖的东西仍然符合微软的一贯作风：花一分钟就可以让他运行，但是要花一辈子才能让他符合要求。（比如说还有 Dynamic Data 这个东东）

我不否认微软做了很多努力让非程序员定制 Sharepoint 很简单，但是当你有一天坐在办公室里听到领导的各种“合理要求”，然后告诉你公司的 sharepoint 花了很多钱，你要充分利用起来时，心里要多郁闷有多郁闷。

在我看来 Sharepoint 最大的问题就是定位不准确。

现在的情况是：

第一，非软件开发类的公司想用 Sharepoint 是期望 IT Pro 来管理/定制 Sharepoint。但是，如果想用好 Sharepoint 是需要使用 .net 进行二次开发的。而且，规模还不算太小。问题来了，非软件开发类的公司既没有经验，也没有人力，也不愿意花费时间、预算来进行这样规模的开发、测试、维护。那怎么办？要么凑合用，要么找公司来代替开发，要么放着不用了。

第二，尽管可以列举出无数的不需要编写代码的、不需要用到 Visual Studio 的 Sharepoint 典型应用。仅仅使用 Sharepoint Desinger 就可以。但是当真正的为公司的实际业务做定制的时候，不写代码是不可能的。甚至极端的情况，Sharepoint 提供的那些 Web Parts、List 等等，几乎很少用到。就拿我现在做的一个项目来说，我用 Custom List 存放公司员工的请假申请。我花了很少的时间，做好了工作流+Infopath表单，花了非常多的时间来制作分析这个 List 数据的页面。如果这些数据存放到一个 SQL 表里面，后面的这些工作用不了现在1/2的时间就够了。这就是我要说的第三点。

第三，为什么 Sharepoint 的数据和视图是混合的？为什么不是分离的？可以单独创建 View 不好么？现在的 Sharepoint 并不是不能分离 View 和 List/Lib，向我现在就是通过自定的 Web Part 来处理 List。结果是什么呢？Sharepoint 提供的一大片功能浪费掉了……

问题说完了，提几点希望吧。

首先，Sharepoint 的定位一定要明确，要么就是给 IT Pro，要么就是给 Developer。当然，我的意见是干脆做给 Developer 用。接下来几点是针对定位给 Developer 来说。

其次，把 View 和 List/Library 分开，让 List/Lib 看上去就像一个 Database Table 一样。View 查询 List 里面的数据通过 Linq to Sharepoint（现在有一个山寨版的这样的项目，希望微软能弄个官方的出来）。

最后，BDC 是不是也可以考虑用 Linq to ..... 替换掉？

以上抱怨来自感受到无论如何不从头写 Web Part 没法实现实际的需求。