14 个解决方案
#1
你是基于SharePoint做开发呢，还是只是数据存在SharePoint，然后全用asp.net开发一个web站点呢？
这样是有很大区别的；
如果整个站点基于SharePoint开发，一般情况都是：
自定义MasterPage；
自定义WebPart，用于功能、展示等等；
自定义一些web application page等；
然后，是一个同意的解决方案。
可能还会用到EventReceiver（事件触发器）和TimerJob（计时器任务）等，这是SharePoint的开发模式；
如果用asp.net开发，就调用或者自定义需要的接口就行了。
这样是有很大区别的；
如果整个站点基于SharePoint开发，一般情况都是：
自定义MasterPage；
自定义WebPart，用于功能、展示等等；
自定义一些web application page等；
然后，是一个同意的解决方案。
可能还会用到EventReceiver（事件触发器）和TimerJob（计时器任务）等，这是SharePoint的开发模式；
如果用asp.net开发，就调用或者自定义需要的接口就行了。
#2
是基于SharePoint开发的，用到sharepoint主要是用搜索和文档版本管理功能，其他的基本都要自定义实现，一套前端页面都需要自定义，后端的沿用sharepoint开发，这个跟你说的基本上是一致的，我就是想知道，如果前端的开发工作量比较大，用sharepoint的相关对象例如：SPList,SPListItem,SPWeb 用这些对象写代码一个复用性不高，另一个这些对象不支持序列化。
为了节约开发成本，我们需要代码可复用性高，因为接着好几个项目都是类似的需求，只是数据库表字段变了（sharepoint就是列表字段变了）。这样再做一个新项目，除了公共的webpart可复用，其他基于列表的业务操作基本都得再写了。
所以在这里发个帖子 看看大家有什么好的做法，或者好的设计框架。
#3
补充一下，业务变化，业务操作代码自然会变化，我的意思就是能抽取出来公用的部分大概能有多少，能抽些什么出来。
#4
也就是从框架和设计上考虑后续的sharepoint项目需求，对后续的项目有些积累，如.net项目三层框架搭好了，各底层实现都做了，剩下的开发只需要针对业务和UI做开发就可以了，不需要考虑更多底层的东西。异常捕捉，日志记录，这类都是可共用的，可提取的。
#5
建议继续用ASP.NET实现
#6
用asp.net工作量比较大啊。。。那样就真纯粹把sharepoint当数据库了。。
#7
你把字段放开，写到属性里或者配置文件里，到时候去读，可重用性会好很多，就是开发的时候，麻烦一些，重用性就好很多；
比如你一个读新闻的WebPart，可以把写个属性“Title;Body;Author”，然后程序里去读，甚至前台的template也可以定义好；
比如你一个读新闻的WebPart，可以把写个属性“Title;Body;Author”，然后程序里去读，甚至前台的template也可以定义好；
#8
这样的写法对只做展示用的webpart是比较通用的，其他用于对splistitem操作的呢？你想想每个列表做业务操作时，都是通过内部名来取值赋值，比较麻烦，也不通用。
#9
这个还是可以的呀！！！！！！！！！！！
#10
不知道我的理解对不对，楼主想要得是一个SharePoint列表操作的扩展类库，类似于SQLHelper操作数据库一样，可以比较方便的操作SharePoint列表。
这个可以通过扩展方法添加到SharePoint对象中(也可以模仿sqlhepler单独写一个helper类)，但是这些可能是要自己在项目里总结提取了......
有了这个类库，剩下的跟传统的.net开发就没多少区别，你可以用sharepoint solution也可以用.net web application
这个可以通过扩展方法添加到SharePoint对象中(也可以模仿sqlhepler单独写一个helper类)，但是这些可能是要自己在项目里总结提取了......
有了这个类库，剩下的跟传统的.net开发就没多少区别，你可以用sharepoint solution也可以用.net web application
#11
楼上的说法，其实很好。。
#12
我觉得架构可以使用.net的架构设计，只要是把UI和业务逻辑分开就可以了。对于业务逻辑的话，只能是积累自己的类库（包括你提到通用的模块，控件）等等可复用的代码，来提高开发效率，也有一些企业应用架构设计的书，讲到一些架构但是未必适用于SharePoint的开发。
一般来说，建一个VS Solution的模板，使用一个熟悉的架构设计（比如三层架构）作为架子，把自己的类库引用进来，基本上就只剩下写UI和业务逻辑了。我有一个常用的框架，仅供参考：http://blog.csdn.net/shrenk/article/details/17509059
谢谢。
一般来说，建一个VS Solution的模板，使用一个熟悉的架构设计（比如三层架构）作为架子，把自己的类库引用进来，基本上就只剩下写UI和业务逻辑了。我有一个常用的框架，仅供参考：http://blog.csdn.net/shrenk/article/details/17509059
谢谢。
#13
SharePoint 没有三层的概念，但是你可以写page，web 和Webpart 部署到你的SharePoint环境里去。
#14
感谢大家的讨论 结贴给分了。。。
#1
你是基于SharePoint做开发呢，还是只是数据存在SharePoint，然后全用asp.net开发一个web站点呢？
这样是有很大区别的；
如果整个站点基于SharePoint开发，一般情况都是：
自定义MasterPage；
自定义WebPart，用于功能、展示等等；
自定义一些web application page等；
然后，是一个同意的解决方案。
可能还会用到EventReceiver（事件触发器）和TimerJob（计时器任务）等，这是SharePoint的开发模式；
如果用asp.net开发，就调用或者自定义需要的接口就行了。
这样是有很大区别的；
如果整个站点基于SharePoint开发，一般情况都是：
自定义MasterPage；
自定义WebPart，用于功能、展示等等；
自定义一些web application page等；
然后，是一个同意的解决方案。
可能还会用到EventReceiver（事件触发器）和TimerJob（计时器任务）等，这是SharePoint的开发模式；
如果用asp.net开发，就调用或者自定义需要的接口就行了。
#2
是基于SharePoint开发的，用到sharepoint主要是用搜索和文档版本管理功能，其他的基本都要自定义实现，一套前端页面都需要自定义，后端的沿用sharepoint开发，这个跟你说的基本上是一致的，我就是想知道，如果前端的开发工作量比较大，用sharepoint的相关对象例如：SPList,SPListItem,SPWeb 用这些对象写代码一个复用性不高，另一个这些对象不支持序列化。
为了节约开发成本，我们需要代码可复用性高，因为接着好几个项目都是类似的需求，只是数据库表字段变了（sharepoint就是列表字段变了）。这样再做一个新项目，除了公共的webpart可复用，其他基于列表的业务操作基本都得再写了。
所以在这里发个帖子 看看大家有什么好的做法，或者好的设计框架。
#3
补充一下，业务变化，业务操作代码自然会变化，我的意思就是能抽取出来公用的部分大概能有多少，能抽些什么出来。
#4
也就是从框架和设计上考虑后续的sharepoint项目需求，对后续的项目有些积累，如.net项目三层框架搭好了，各底层实现都做了，剩下的开发只需要针对业务和UI做开发就可以了，不需要考虑更多底层的东西。异常捕捉，日志记录，这类都是可共用的，可提取的。
#5
建议继续用ASP.NET实现
#6
用asp.net工作量比较大啊。。。那样就真纯粹把sharepoint当数据库了。。
#7
你把字段放开，写到属性里或者配置文件里，到时候去读，可重用性会好很多，就是开发的时候，麻烦一些，重用性就好很多；
比如你一个读新闻的WebPart，可以把写个属性“Title;Body;Author”，然后程序里去读，甚至前台的template也可以定义好；
比如你一个读新闻的WebPart，可以把写个属性“Title;Body;Author”，然后程序里去读，甚至前台的template也可以定义好；
#8
这样的写法对只做展示用的webpart是比较通用的，其他用于对splistitem操作的呢？你想想每个列表做业务操作时，都是通过内部名来取值赋值，比较麻烦，也不通用。
#9
这个还是可以的呀！！！！！！！！！！！
#10
不知道我的理解对不对，楼主想要得是一个SharePoint列表操作的扩展类库，类似于SQLHelper操作数据库一样，可以比较方便的操作SharePoint列表。
这个可以通过扩展方法添加到SharePoint对象中(也可以模仿sqlhepler单独写一个helper类)，但是这些可能是要自己在项目里总结提取了......
有了这个类库，剩下的跟传统的.net开发就没多少区别，你可以用sharepoint solution也可以用.net web application
这个可以通过扩展方法添加到SharePoint对象中(也可以模仿sqlhepler单独写一个helper类)，但是这些可能是要自己在项目里总结提取了......
有了这个类库，剩下的跟传统的.net开发就没多少区别，你可以用sharepoint solution也可以用.net web application
#11
楼上的说法，其实很好。。
#12
我觉得架构可以使用.net的架构设计，只要是把UI和业务逻辑分开就可以了。对于业务逻辑的话，只能是积累自己的类库（包括你提到通用的模块，控件）等等可复用的代码，来提高开发效率，也有一些企业应用架构设计的书，讲到一些架构但是未必适用于SharePoint的开发。
一般来说，建一个VS Solution的模板，使用一个熟悉的架构设计（比如三层架构）作为架子，把自己的类库引用进来，基本上就只剩下写UI和业务逻辑了。我有一个常用的框架，仅供参考：http://blog.csdn.net/shrenk/article/details/17509059
谢谢。
一般来说，建一个VS Solution的模板，使用一个熟悉的架构设计（比如三层架构）作为架子，把自己的类库引用进来，基本上就只剩下写UI和业务逻辑了。我有一个常用的框架，仅供参考：http://blog.csdn.net/shrenk/article/details/17509059
谢谢。
#13
SharePoint 没有三层的概念，但是你可以写page，web 和Webpart 部署到你的SharePoint环境里去。
#14
感谢大家的讨论 结贴给分了。。。