I colleague of mine just told me about Mark Everards response to my previous post about EPiServer. Without trying to turn this into some blog-battle, I’ll give my response.
I’m well aware of PageTypeBuilder, a few problems however: It’s not supported by EPiServer and it’s third party. Why would you pay for a proprietary CMS if you have to patch it with third party unsupported code? And this is no small patch/change, it rewrites the entire way you deal with “PageTypes” in EPiServer, effecting the entire system. How do you explain to your client that there is no support available for parts of the CMS they paid for? That if there are problems with certain components the client has to pay to fix them. You can also turn the argument of PageTypeBuilder around; EPiServers core design is so bad that you have to patch it to make it usable.
The issue with pages would not be so big if EPiServer admin interface wasn’t totally locked into this model, you will mostly end up writing your own administration interface for any data that doesn’t fit into the EPiServer model.
About the Dynamic Data Store, or DDS for short. Looked at it, don’t like it. It’s basically ‘one big ugly hack’ to fit something akin to the “NoSQL”-databases inside EPiServer and on-top of SQL Server. Speed is going to be abysmal. It’s going to get abused. In the comments to the post “Introducing The Dynamic Data Store” someone from EPiServer say they have benchmarked it up to one million rows, I’m sorry but one million is nothing. Hell for one million rows a flat file append-only b-tree + an in memory dictionary is better. Also I’m not sure of how they intend to solve indexing this huge SQLServer table (maybe they have, if so someone please enlighten me).
Also, this quote really struck a nerve with me:
“Is it really fair to judge a piece of software by what it can’t do rather than what it can? EPiServer won’t meet your requirements as a business accounting and reporting system but as a Web Content Management system it certainly can.”
Yes, it is. If EPiServer is not flexible enough to meet the demands we have (and they are not very exotic ones) then it’s more then fair to judge it on that.
Yes the documentation at sdk.episerver.com has gotten a bit better, it’s got a long way to go until it’s up to par to even most open source software (these guys don’t even get paid, and have better documentation than EPiServer – there is no excuse for it being this bad). Of course I know about world.episerver.com, but is that really the answer: “What you’re looking for might be in these unsorted blog post scattered over some/several websites”. That’s not the type of documentation I want from a product I pay for. It should be indexed, categorized, nicely searchable and written by the people that have built the software and updated with every new release.
What would you say if your new car stereo came with a slip that said: “Google for <model-name> and you’ll probably find something, we hope”. Somehow this is acceptable for EPiServer (and a lot of other commercial software).
About EPiMVP and EPiAbstractions, yes I know about them and played around with them. EPiMVP isn’t even a 1.0 release yet and EPiAbstractions is not updated to the latest version of EPiServer (from what I can see, latest release on CodePlex is from September last year). These still fall under the same arguments as PageTypeBuilder: Unsupported, third-party plugins you will end up being responsible for yourself towards the client – that are used to patch core defects in EPiServer that shouldn’t be there from the beginning.
It’s pretty much the same conclusion as the last time, do you really want to pay for a proprietary product that you will have to patch with third party code to make usable? Maybe you want to be responsible for third party party code towards your clients? I don’t.
Also on a code level it just scares me to use a CMS that is built by people who think that using a singleton class (DataFactory.Instance) for all database access is a good idea.