I'd like to share with you this link. Outstanding programming resource, clean easy-to-read style. Bravo Scott! I already ordered your Programming Windows Workflow Foundation book.
Tuesday, January 08, 2008
Friday, January 04, 2008
To me, what is really bad in SharePoint - in general - is that it mixes together data, business logic, and presentation. Everything is in the list. The good standard multi-tier design (database layer – business layer – presentation layer) was developed and used over many years. Data is supposed to be stored in database, not in a list. But SharePoint does not easily allow plugging an external database. You are not supposed to work with its underlying cryptic SQL database either. SharePoint does not want to be a presentation layer. It wants to be an all-in-one machine. I never saw good all-in-one machines. They consume an enormous amount of resources but are never flexible enough to suite concrete needs.
Personally, I'm not very happy with ASP.NET View State and ASP controls which try to blur a boundary between server-side scripts and client-side controls either. I'm not entirely happy with applying well-working Windows desktop event model to very different world of Web applications either. Are you a big fan of Big Ball of Mud?
I always thought that it is generally healthier to separate client logic and server logic. Ajax (which I like and use for a long time) does not try by itself to blur that distinction between server and client.
Apparently, it’s not only my concern: some people at Microsoft think in that direction as well. Otherwise, why they're now introducing in ASP.NET a long-known and proven MVC design pattern?
But, besides these philosophical design considerations, our team stumbled against major problems in our attempts to switch company's intranet from old classic ASP to SharePoint. After months of learning, after participating in SharePoint Connections 2007 conference we finally – and to my big relief – decided to develop in ASP.NET 3.5 instead. We are pretty sure that MOSS security model (based on groups and similar to Windows itself) is not flexible enough and does not allow us to implement our company's business rules in a natural way.
I don't agree with an author of article mentioned below when he says that our company business rules are unique. I see them as quite normal and natural. It's enough to say, that they lie perfectly to a good relational database design for Roles and Rights we use right now and going to continue to use with ASP.NET version of our intranet.
Here's why we decided that SharePoint is not our tool
Somewhat related articles:
Why SharePoint Portal Server is Terrible
Things you should know about SharePoint ahead of time
SharePoint 2007: Pointedly unskinnable
The Long Path to Content Deployment
Missing MOSS 2007 Functionality