Ok, so I have another random question, this time regarding the usability and architecture of the Web Client Software Factory.

Basically, IMO, it guidance package is pretty cool from an automation / guidance standpoint.

From a functional application architecture, I think the number of moving parts involved with creating applications using the Web Client Software Factory is a load of crap. I think that there are way too many moving parts for creating your UI screens. I also think that when moving from project to project maybe 5% of the UI code may be reused in the next project, so I dont think that the MVP / MVC buys you anything except a maintenance nightmare and extended training sessions for consultants and jr. developers.

Anyone else have any thoughts regarding the "real world" use of this guidance package?

As far as I know the main idea of MVP/MVC is for example: 1. You create a Windows Form project. 2. Then later you want to create Web UI for the same project, in this case you see the gain of using MVP/MVC.

I do not think that using MVP/MVC will give gain when you move from a project to a different project.

Hmm, thats an interesting perspective that I had not considered. Most of my clients barely want to pay for one flavor of a given UI, much less 2 or 3. But I do see your point.

I have used it on a couple of medium-sized projects.

It has quite a few bugs in the current release that are a pain. If you plan to evalute it, I recommend waiting for version 1.1 which is supposed to be out this month.

Model-View-Presenter is optional in the WCSF and mainly used for testability of the UI. It also does abstract your application from the view, so you could use it with other projects but also with different views in the same project. The WCSF Team doesn't push the MVP Recipes, just provides them for you if your project needs it. If you do need MVP, the recipes are a huge productivity savings.

The WCSF also has Dependency-Injection, Service Registration and Location, Page Flow, and other nice features. The Page Flow Application Block is really sweet when you have complex page flows and you want to have the ability to maintain them separately using WF. So, it is more than MVP and there are some nice features.

If your application could benefit from such features and you aren't up on all the technology, the WCSF is a nice starting point.

If your application doesn't need the features, it is overkill.

If you are already familar with the features and have your own solutions to these challenges, you may find the WCSF a bit less functional it its 1.0 version.

For smaller applications or applications that are primarily CRUD database applications with little business logic and little need for flexibility and extensibility, this is not the answer.

WCSF 2.0 is expected to have more Rails-like features, but that won't happen until closer to end of the year.

Regards,

Dave

Hello Dave,

Thanks for the post. The direction taken by most of the apps that I work on have 85% of the functionality contained in WebUserControls. Then we simply pop the controls onto pages. So I need to look more at leveraging WCSF for how my organization develops apps.

I did also notice that WCSF uses DI, Service Registration & Location, and PageFlow via WF. I havent looked at these features yet (but they are on my list). I think what I will most likely do is look at their samples as see how I can morph their framework for these features into how my organization builds apps.

In anycase, these new features (DI, Services, and PageFlow) are pretty cool and on the surface seems like they would be beneficial.

Hopefully someday the practices team will publish some documentation on the ObjectBuilder framework as I just dont have the time to reverse engineer their code.

Smart thinking - Your days will probably be a lot more stress free if you just incorporate what you can from the WCSF in your own architecture. Microsoft and P&P have a history of being very slow in providing bug fixes and enhancements in their solutions.

You can definitely just pull out the Composite Web UI Application Block (CWAB) and the Page Flow Application Blocks for your own use. The GAX recipes can be customized and used in your applications, too.

The lack of ObjectBuilder Documentation is horrendous. I only use it because my customers are often Microsoft shops and I can't get around it. We really need a Dependency Injection Application Block from P&P so we don't have to deal with ObjectBuilder directly.

Regards,

Dave

Hi Dave, glad to see you here again

I talked to Olaf Conijn today, he wrote the policy injection block I think for Entlib. To bad I read this info now, so I couldn't give him this feedback. Anyway, they've started a contrib project very recently, so perhaps the tooling will become better.

Thanks, Frans!

Oooops... I didn't mean to say Policy Injection Application Block ( PIAB ) I changed it above. I meant to say Dependency Injection Application Block.

What we need is a new application block, called the Dependency Injection Application Block, that gives us similar functionality to Castle Windsor, StructureMap, Spring.NET, etc. ObjectBuilder is just a framework to build dependency injection tools, but since it has no documentation to speak of it is a pain to get to work. And the containers built into the Smart Client and Web Client Factories leave a developer wanting more.

The PIAB is actually nice for a 1.0 release. It opened my eye to Aspect-Oriented Programming and has some really cool integration with the validation, logging, and other EntLib Blocks. It comes at a bit of a performance hit, but it sure does clean up your code and expose its true intentions. It also gives you some really nice run-time control over your application via configuration if and when you need it.

Regards,

Dave