Questions about features, the architecture used and future.

[mike_f]

Hi,

I'm a systems architect responsible for making a pre-study on a webstore system for a customer. We need to find a well-done e-commerce base to extend from and have heard a lot of good about AbleCommerce.

I originally sent this as an email to the salesrep that contacted me but was told this would be a better place to ask my questions as they are of a more technical nature. Please note that even though the questions are put in a "why..."-format they are not necessarily intended as critique but express my will to fully understand why the system is built the way it is.

Here goes:

1. Why use WebForms UI Model (postback/viewstate) without implementing MVP or MVC pattern? This, to me, really is something i thought was more common a few years ago and I am a bit surprised to find it here. The rigidness of postback- and viewstate-driven models together with the inability to have good test-coverage makes it less than favorable. Care to share your thoughts on this?

2. Why no ORM- or DB-abstraction-layer? The DAL is built into the "server"-part of the application and even though I cannot say with confidence that I have grasped the DAL and the domain model completely yet, it seems that extending the database poses difficulties. I can see that you use ObjectBuilder in the serverlibraries, but perhaps it would have been beneficial for extensibility to incorporate an open object-model based ORM layer as part of the opensource part, based on a common free ORM framework like NHibernate or SubSonic. For instance we need to extend both the customer metadata from a backend financial system and the product metadata with product information from CNet. How could this be done easily with the current architecture?

3. Why don't you use any proper service-layer design patterns, like servicelocator or any DI/IOC framework? There are a bundle of prime containers and mini-frameworks out there that would make the services used more loosely coupled and configurable. It would also be much easier mocking services for unit-testing with such a layer.

4. Why use inline code in all pages instead of code-behind? Inline code in a single file is much harder to read, maintain and debug and also causes problem with intellisense and possibly other plugins and tools (resharper comes to mind). I think it is good practice to separate actual code from strictly GUI html and ever since 2.0's implementation of partial classes this would be the preferred way to manage the code. I am very curious as to why this is not done in AC?

5. Why isn't the application properly localized yet? Even though the US probably is your biggest market and where you focus your efforts, i expected a system of this magnitude to be properly localized and resource-based. This is clearly not done, and the code is littered with static texts, both in code and in UI. Mind you, that a properly resource-based application isn't beneficial only for international customers, but also simplifies maintenance of the store texts and design. I would much rather send my customer a resource-file that he can prood and update to his own desires, rather than having him take notes and making changes in the code...
Reading the forum, there have been a multitude of requests for this ever since early 2007 and the response from you back then was that is coming in the next release. We are now at 7.1 and mid-Q1 2009, and still no sign of it?

6. Quality code. Sure, I cannot say that I see and bad code anywhere, but I am a bit curious as to why the code isn't cleaned up or refactored more. The code (at least the bits of it that I am privy to) is strewn with redundant initializations, qualifiers, casts and includes. One reason for redundancy would be clarity but from what i saw, this was not the case and I would rather call it clutter. Is this just due to old code that hasn't really been tidied up lately?

7. Extensibility? Another big concern of mine is the extensibility of the system. Are there any guidelines on how to extend the base system in any pre-defined way that will ease a future upgrade of the underlying "server" and framework part? With the extensions in model and functionality I have in mind, I would be very interested in how a future upgrade to AC 8.0 (or whatever will come next that is worth an upgrade and the effort it entails) would work?

8. Performance. I've been trying to find information about performance and stability of the system (out-of-the-box and without any modifications of course). It is vital that the system perform well and is responsive even though the load might be big. Any statistics on transactions/hour, general stability/uptime etc that you can provide?

Besides these questions and thoughts i have i think AbleCommerce seem to be a very full-grown and extensive system and there are ofcourse many parts of it i like very much (otherwise i wouldn't be here asking these questions at all), but i see no point in bringing that up here as it adds nothing valuable to this discussion at this time. I'll give you praise later on, when, and if, i am done and the store is launched...

Thanks again,

/Mike

[Logan Rhodehamel]

1. Why use WebForms UI Model (postback/viewstate) without implementing MVP or MVC pattern? This, to me, really is something i thought was more common a few years ago and I am a bit surprised to find it here. The rigidness of postback- and viewstate-driven models together with the inability to have good test-coverage makes it less than favorable. Care to share your thoughts on this?

This initial answer will touch on some of your other points.

Would it surprise you to learn the AC7 project began over two years ago? At the time, VS2005 and .NET 2.0 were new. Choices we made then are not necessarily the same we would make now. Over time the patterns have matured and better practices with ASP.NET have come to light.

I agree about the lack of test coverage. I can see the potential with MVP to alleviate that. It is possible that our client side scripts will evolve. Still, the WebForms model is not wholly invalid. One positive aspect is that it is more familiar to intermediate designer/developers. This forms a lot of our target audience. The event driven web form has less of a learning curve for the majority of our customers who are not developers by nature.

2. Why no ORM- or DB-abstraction-layer? The DAL is built into the "server"-part of the application and even though I cannot say with confidence that I have grasped the DAL and the domain model completely yet, it seems that extending the database poses difficulties. I can see that you use ObjectBuilder in the serverlibraries, but perhaps it would have been beneficial for extensibility to incorporate an open object-model based ORM layer as part of the opensource part, based on a common free ORM framework like NHibernate or SubSonic. For instance we need to extend both the customer metadata from a backend financial system and the product metadata with product information from CNet. How could this be done easily with the current architecture?

Why indeed! If you ask Sohaib or I, this is probably something we both wish were different. It goes back to the timeframe - the persistence frameworks were almost there, but not quite. I tested several of the most promising ones, including NHibernate. But the bottom line was we could not build an application based on the hope that our chosen framework would mature.

There are ways to extend the data, it depends on which approach you favor. Most people do not purchase the library source code. In these cases, extended data is stored in additional tables and custom classes are produced. There is a reference post in the forum where Mazhar has posted templates that use MyGeneration to approximate the same features of our data layer.

3. Why don't you use any proper service-layer design patterns, like servicelocator or any DI/IOC framework? There are a bundle of prime containers and mini-frameworks out there that would make the services used more loosely coupled and configurable. It would also be much easier mocking services for unit-testing with such a layer.

These are some discussions we have held internally... but these types of adjustments cannot take place during minor upgrades. We released 7.0 final almost a year ago. Changes since then can best be described as refinement. There are new features to be sure, but we are not making any radical changes to the design.

4. Why use inline code in all pages instead of code-behind? Inline code in a single file is much harder to read, maintain and debug and also causes problem with intellisense and possibly other plugins and tools (resharper comes to mind). I think it is good practice to separate actual code from strictly GUI html and ever since 2.0's implementation of partial classes this would be the preferred way to manage the code. I am very curious as to why this is not done in AC?

Again refer back to timeframe. If I am recalling correctly, Intellisense in in VS2005 would not work properly with code-behind pages for C#. There were also minor concerns about ease of file renames as the development was in heavy flux. However, about six months ago we found a blocker issue with inline code that relates to site compilation and deployment. Since then we have been steadily converting pages over to code-behind. Code-behind is the offical company policy now.

5. Why isn't the application properly localized yet? Even though the US probably is your biggest market and where you focus your efforts, i expected a system of this magnitude to be properly localized and resource-based.

Localization is a top priority. I expect this to be one of the issues we discuss within the next couple of weeks.

6. Quality code. Sure, I cannot say that I see and bad code anywhere, but I am a bit curious as to why the code isn't cleaned up or refactored more. The code (at least the bits of it that I am privy to) is strewn with redundant initializations, qualifiers, casts and includes. One reason for redundancy would be clarity but from what i saw, this was not the case and I would rather call it clutter. Is this just due to old code that hasn't really been tidied up lately?

It's possible. It's hard to say without having a particular example. Generally I am satisfied with the quality of the product. Changes undergo a system of peer review, and every once in a while someone will catch something that could be handled better.

7. Extensibility? Another big concern of mine is the extensibility of the system. Are there any guidelines on how to extend the base system in any pre-defined way that will ease a future upgrade of the underlying "server" and framework part? With the extensions in model and functionality I have in mind, I would be very interested in how a future upgrade to AC 8.0 (or whatever will come next that is worth an upgrade and the effort it entails) would work?

The framework uses partial classes. If you were to extend it directly, in some cases you may be able to tack on an additional file. In other cases you may be able to keep your extended code contained within separate classes.

Usually we encourage people who are able to extend the application without modifying the framework directly. This ensures the maximum chance that future upgrades will be successful and without work. But when frameworks get modified, there is little substitute for good source control, change tracking, and a merge utility.

8. Performance. I've been trying to find information about performance and stability of the system (out-of-the-box and without any modifications of course). It is vital that the system perform well and is responsive even though the load might be big. Any statistics on transactions/hour, general stability/uptime etc that you can provide?

These are always difficult questions to answer because it depends on many factors, ranging from equipment to customer patterns. Perhaps it is better addressed by some of our existing merchants who have had live 7.0 stores through this past holiday season.

[mike_f]

Hi Logan,

Thanks for your quick and thorough response. Yes, i had a feeling that AC7 had a few years on it's back, which is quite usual, at least in larger commercial applications. I have no beef with the webform model other than that i like others better for previously named reasons. I also did not mean to say that your product are of inferior quality, i was just curious about some redundant parts of the code (and redundant in this context not implying bad or wrong, just...redundant)

The issue with localization is actually also one of my top concerns. I feel that i would not like to put a lot of effort into converting the application to be localized only to find a new release a short while later which incorporates that. Do you have any time-estimate on when such a version could be ready? Several users on these boards have stated that it is quite simple to do it, and shouldn't it be even simpler for you to just do the localization once and for all and do a service release of that (7.15 springs to mind =)?

I for one would really appreciate that, and in my case that would actually immediately "seal the deal" on which system i will to take to the next level...

/Mike