New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Visual Studio Extensions for SharePoint Released
Posted by Jonathan Allen on Jun 10, 2008
SharePoint is rapidly becoming the default CMS platform for companies building internal website using Microsoft technologies. SharePoint, though loaded with features out of the box, is often heavily customized using ASP.NET. In order to facilitate that, Microsoft has recently released several resources for both new and experienced SharePoint developers.
In order to make SharePoint projects easier to start, Microsoft has created Visual Studio Extensions for SharePoint. The VS 2005 edition was released in February and the 2008 edition just a few days ago. The User Guide, Samples, and Walkthroughs for the VS 2005 edition (version 1.1) are currently available. The documentation for the VS 2008 edition (version 1.2) is expected later this month.
Microsoft has also launched a new SharePoint site dedicated to bringing developers up to speed with the relevant technologies. The site is still under construction with a lot of interesting topics listed as stubs without much content. When complete it appears that each topic will include a virtual lab, webcast, screencast, quickstart guide, whitepaper, and downloadable hands-on lab.
RelatedVendorContent
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
Five Key Practices to Agile ALM
Case Study: IBM's Agile Transformation
agility@scale eKit: 10 Principles, Scaling Model, Metrics, Collaboration
The first rule of SharePoint development
by
Ryan R
Posted
Re: The first rule of SharePoint development
by
Steve Macdonald
Posted
Re: The first rule of SharePoint development
by
Ryan R
Posted
Re: The first rule of SharePoint development
by
Ryan R
Posted
Re: The first rule of SharePoint development
by
Bjørn Stærk
Posted
-
...is don't do any SharePoint development.
If a client is requesting functionality that SharePoint doesn't provide OOTB or through third party components or webparts, consult them away from SharePoint. You are asking for trouble if you get into a project that will require heavy SharePoint coding and customization. -
Ryan,
That's a rather broad statement. Can you provide specific examples to support your contention? -
There are quite a few arguements here:
codebetter.com/blogs/jeffrey.palermo/archive/20...
I will summarize some of the major issues with SharePoint devleopment.
Server development.
Development must be done on the server. Because of this, I have literally seen teams of developers deving directly on servers running SharePoint, over a Remote Desktop. Why were they working on the server? Their laptops were not powerful enough to run VMs of SharePoint (which is the preferred client development environment).
Code and asset synchronization.
There is no automated way to synchronize all development and SharePoint assets across a team of developers and integrators. This is brutal because you end of having 70% or so of you development assets in a SCC system, and the rest within your shared SharePoint development system itself. There is no easy way to synchronize everything across a team. You end up with developers working in their VMs and integrators working on a single environment. With that setup, everything must be properly synchronized. This is the fundamental issue with team based SharePoint development
Debugging
There is no easy or streamlined way to debug code. Debugging is very labor and time intensive on SharePoint and very prone to breaking (no pun intended).
Use of Lists
SharePoint proponents and pundits are encouraging the use of SharePoint as an alternative to a relational database for persistent data storage. This is very dangerous. You are essentially locking up enterprise data within SharePoint and eventually, you will need to get that data out. That won't be a pleasant experience.
There are some more reasons, but these are the ones I have encountered.
I think SharePoint, as a tool, is fantastic if used in the proper situation and environment. I have seen some people do interesting things with it without writing much code. I just don't think it's mature enough as a platform to do any rapid development. The learning curve is massive, configuration can be tricky and deployment is convulted. The toolset isn't very mature yet. -
There are quite a few arguements here:
codebetter.com/blogs/jeffrey.palermo/archive/20...
I will summarize some of the major issues with SharePoint devleopment.
Server development.
Development must be done on the server. Because of this, I have literally seen teams of developers deving directly on servers running SharePoint, over a Remote Desktop. Why were they working on the server? Their laptops were not powerful enough to run VMs of SharePoint (which is the preferred client development environment).
Code and asset synchronization.
There is no automated way to synchronize all development and SharePoint assets across a team of developers and integrators. This is brutal because you end of having 70% or so of you development assets in a SCC system, and the rest within your shared SharePoint development system itself. There is no easy way to synchronize everything across a team. You end up with developers working in their VMs and integrators working on a single environment. With that setup, everything must be properly synchronized. This is the fundamental issue with team based SharePoint development
Debugging.
There is no easy or streamlined way to debug code. Debugging is very labor and time intensive on SharePoint and very prone to breaking (no pun intended).
Use of Lists.
SharePoint proponents and pundits are encouraging the use of SharePoint as an alternative to a relational database for persistent data storage. This is very dangerous. You are essentially locking up enterprise data within SharePoint and eventually, you will need to get that data out. That won't be a pleasant experience.
There are some more reasons, but these are the ones I have encountered.
I think SharePoint, as a tool, is fantastic if used in the proper situation and environment. I have seen some people do interesting things with it without writing much code. I just don't think it's mature enough as a platform to do any rapid development. The learning curve is massive, configuration can be tricky and deployment is convulted. The toolset isn't very mature yet. -
Ryan, you have some good points, but I would call them overcomable obstacles and not reasons to avoid Sharepoint. That is, if your organization is serious about developing on Sharepoint, there are some challenges you have to solve, challenges the marketing people at Microsoft don't tell you about. This is not so different from any development platform - there are always hidden pitfalls and shortcomings to balance against whatever strength the platform has.
"Development must be done on the server."
This is an annoyance, but not a showstopper. You can run Windows Server on your development computer, or you can develop on one computer and deploy to another (this is what we do). Also a company called Bamboo has created a hack to let you run Sharepoint on Vista.
"There is no automated way to synchronize all development and SharePoint assets across a team of developers and integrators."
Microsoft is partly to blame here for selling Sharepoint Designer as a development tool. It's not, it's a tool for power users. If you use it for development, you'll end up as you say with only part of your work in source control and the rest in some Sharepoint database. A little foresight and discipline is needed to avoid this. One solution is to create Sharepoint solutions, but I'm not entirely happy with that, (partly because they're difficult to create - but there are tools on Codeplex that help with this). Part of the problem is that deployment in general is a weak point in ASP.Net. At our company we have made deployment tools to help with this, which makes it easy to synchronize all the work across various installations.
"You are essentially locking up enterprise data within SharePoint and eventually, you will need to get that data out. That won't be a pleasant experience."
The upside of lists is that you get the storage and presentation code for free, which is a huge timesaver, (in fact the primary strength of Sharepoint is the way it gives you powerful building blocks that you can combine in clever ways with very little effort). The data is not locked away. Exporting it takes only a couple of lines of code against the Sharepoint API, no more difficult than if you were to export from one database to another. That said lists should not be seen as a replacement of the relational database - if you need anything more complex than a flat table of data, you may be better off writing your own storage code, (you can still reuse the Sharepoint presentation code with something like SPGrid).
"I just don't think it's mature enough as a platform to do any rapid development. The learning curve is massive, configuration can be tricky and deployment is convulted."
I would say that your criticism is all correct in type but not in scale, ie. you're right but in the development situations where Sharepoint is relevant it's not a major obstacle. If you're doing medium-to-large scale web development, and you're willing to invest in learning how to use the platform in a smart way, Sharepoint is a very good platform.
Actually, my conclusion would the opposite of yours: Do not think about using Sharepoint as an out of the box product. I know Microsoft is selling it as a finished product, but it's not - it's a development layer on top of ASP.Net. You can do some fun things without development, but that leaves 99% of the possibilities untouched. Give it to some good programmers, give them time to learn the platform, and you'll see some very good, quickly made web applications.
5 comments
Watch Thread Reply