as most of you already know, Commerce Server 2009 is built on the top of Commerce Server 2007 API (called core foundation) that consume the schemas that you define in the several subsystems (Catalog, Marketing,Profiles, Orders)
the first choice that a SharePoint developer (or any developer/architect) has to take, when it comes to Commerce Server is about the project structure to use and the project approach to keep.
the first question is going to be about reusing the Extensibility toolkit or not?!
Unluckily there is not a good answer to this question, common sense would say it depends on your requirements and the specific context of your project…
So I tried to summarize the factors and pro and contras to consider to take the right decision
Extensibility Toolkit
Pro
- It’s easier to kick off the project (specially if you don’t have full CS knowledge)
- It enforces a good software design and enforce some of e-commerce best practices (cookies encryption, stateless sessions, Url rewriting, caching, etc…)
- You will have a lot of code tested and already in place, so if you requirements match with what is in the sample site and web parts, you can reach the code complete very quickly.
- You can extend your UI with XSLT transformations, and web parts parameters, you can as well change the existing web parts and create new ones.
Contra
- Built in web parts rarely can fit in real world customer requirements, personally my clients never asked me about the ability to move web parts and change the look and feel of the web site dragging web parts so I cannot believe that in real world it could happen…
- It doesn’t use Jquery at all, the trend in UI development is to use Jquery everywhere to provide a better customer experience
- In most of the cases you are going to release the code that somebody else did, so you are going to have less governance on the released solution
Custom Site Definition
The alternative to the extensibility toolkit could be to start with a brand new project structure (or in most of the cases, prepare to change an existing project structure, eg. a CMS solution already built and deployed in production with Sharepoint)
Pro
- It will give you the ability to design your solution as you prefer and make your consideration and choice based on your clients existing and future requirements
- It will give you full control on the code that you are going to release and will give you indeed more governance on the project
- It will enforce to use just the CS schemas that you really need
- You will have only the code that you need in your solution
- Your site definition will be tailored on your client specific requirements
- It will be much more easier to maintain and implement future requirement and CS customizations (assuming that you are designing correctly your solution)
Contra
- It will take a bit longer to design and implement it if you don’t have full knowledge on Sharepoint WCM solutions
- It will allow you to make some design and implementation errors that could be avoided following the Extensibility toolkit patterns
At the end of the discussion, I have to say that I saw a lot of Commerce Server projects and in each project I always found some code coming from the Starter site or the Extensibility toolkit and I heard a lot of people complaining about bugs and troubles extending the starter site and Extensibility toolkit….
So my final recommendation for an enterprise project is to go with a custom Site Definition that could reuse some classes from the extensibility toolkit (personally I found quite useful helpers, controllers entities and few other things included in the Common class library).
As well for a small web site to build in a couple of weeks that will not require a lot of maintenance /evolution, I would say just go with the Extensibility Kit and explain to your client that if they want to enforce some cool UI it will be definitively included in next releases….
No comments:
Post a Comment