关于.net系统迁移到sharepoint的方案

[Justin-Liu]

场景如下
有一采用.net框架开发的B/S信息平台系统，大概有10多个业务模块，里面大部分的东西是基础数据、报表、查询、导入导出、联动展示等几个功能点，投入使用中。
现在想把该系统迁移到SP2010 Foundation中，在此征集一些好的建议和方案。

我目前的想法是，用户权限部分SP自带。
对于其中的业务模块、基础数据等，以Site->List的结构进行迁移，其他的一些功能相应地做一些扩展开发。
想过BCS，但该系统今后还将做一些进一步的扩展，如果采用BCS，那做的改进还是只能在原系统进行，不太满足要求。

这个东西个人认为不是一个太简单的过程，比较繁琐。各位有什么好的想法建议请告诉我，有奖征集。

[Justin-Liu]

引用 14 楼 zy_mter 的回复:

我做过一个类似的项目，迁徙一个Win Form 到sharepoint 用LIST 做数据存储。 所有界面都重写。开发时间较长。而且数据导入是通过自己编写代码，导入到list中。 报表用MS SSRS.对于复杂的报表，先写入到临时的SQL数据表中。如果直接用sharepointlist，非常痛苦。 现在回过头来看，用list有好处也有缺点。好处是，直接可以用sharepoint API 比如……

多谢

[Justin-Liu]

最后决定数据库还是沿用SQL 其他的页面UI重新开发 重构权限 开发量不是特别大 多谢各位了 下次来结贴

[天涯海角]

引用 16 楼 FoxDave 的回复:

最后决定数据库还是沿用SQL 其他的页面UI重新开发 重构权限 开发量不是特别大 多谢各位了 下次来结贴

非常明智的选择

[段传涛]

引用 16 楼 FoxDave 的回复:

最后决定数据库还是沿用SQL 其他的页面UI重新开发 重构权限 开发量不是特别大 多谢各位了 下次来结贴

挺好，记得分析你的结果。

[a138043]

对于其中的业务模块、基础数据等，以Site->List的结构进行迁移，其他的一些功能相应地做一些扩展开发。 想过BCS，但该系统今后还将做一些进一步的扩展，如果采用BCS，那做的改进还是只能在原系统进行，不太满足要求。 ------------------------------------------

[zy_mter]

BCS 很不好，不利于扩展如果你的需求很简单 就是写写表单，而且还不需要什么友好的界面。可以用。 否则也很痛苦，和INFOPATH一样，给poweruser 用的。

[Justin-Liu]

找到一篇建议资料跟大家分享一下 To Migrate, or Not To Migrate?

[段传涛]

这么快结了，关于 BCS好不好的问题， 可以继续讨论。

[段传涛]

引用 20 楼 zy_mter 的回复:

BCS 很不好，不利于扩展如果你的需求很简单 就是写写表单，而且还不需要什么友好的界面。可以用。 否则也很痛苦，和INFOPATH一样，给poweruser 用的。

INFOPATH 我们一直没有用，他不是针对专业者。 BCS 是一个便捷的方式 提供扩展数据。

[lhw7791086]

学习了

[pengjun_45]

学习了

[csqiang222]

学习了

[nettman]

[Justin-Liu]

引用 23 楼 jason_dct 的回复:

引用 20 楼 zy_mter 的回复: BCS 很不好，不利于扩展如果你的需求很简单 就是写写表单，而且还不需要什么友好的界面。可以用。 否则也很痛苦，和INFOPATH一样，给poweruser 用的。 INFOPATH 我们一直没有用，他不是针对专业者。 BCS 是一个便捷的方式 提供扩展数据。

原来结贴之后就没有提醒啦。。。 你开一个吧~

[reejayyang]

如果数据量不大的话就放到list里面去，优点：搜索方便 数据量大的话，把数据放到外接的数据库里，sharepoint的portal同样可以外接数据库，数据操作的页面放到list当中，直接访问页面就行了。 做企业内网，sharepoint肯定比asp.net有优势

[taohuirong]

都是高手啊...

[shibamo]

SharePoint其实很差的，后期要改什么东西维护成本很高，得养专门的人来搞。而且工作流的自有方案也极其弱智，纯粹是个骗人的东西。

[潇洒王子]

大概了解过，一直没有机会用。

[areslau08]

最近，我们技术老大看了sharepoint2013，也准备试水！

[风影极光]

我觉得应该从业务复杂程度和重要性上以及项目周期来分析和规划。 1、如果业务简单，不重要，那就用SharePoint的设计元素实现，表单用InfoPath做做就好，尽量使用OOB的解决方案。 2、如果业务复杂，重要，那就基于SharePoint，使用code的解决方案，尽可能使用.Net的原生技术来实现，这样可以以不变应万变的复杂业务需求。