Friday, June 25, 2010

Pradeep's Presentation on Web Client Software Factory

Lately, all of the buzz within ASP.NET has been for ASP.NET MVC. Microsoft’s Patterns and Practice group’s Web Client Software Factory has been around a couple of years. It allows the Model View Presenter (with Passive View) pattern to be applied while still taking advantage of WebForms. I think that the WCSF fits a niche for developments shops with an investment in WebForms can utilize while still offering some benefits of a much more testable and clean development structure. Its recipe-based structure allows for guidance to encourage a consistent approach across the application. Fritz Onion has a nice article providing an overview of the product. WCSF continues to be supported for VS 2010.


In May, I saw an excellent presentation by Pradeep Panthulu on WCSF at a Central PA.NET users group meeting. He has been an architect on a large project that uses WCSF. If I recall correctly, there were at least 40 people on the project. For such a large project, Pradeep found the guidance-based approach of WCSF vital to keep development consistent across the application. Pradeep also showed his architectural expertise by demonstrating the ability to answer questions not directly related to his presentation.


Pradeep found two way data binding to be difficult to accomplish with WCSF. He has ultimately had some success in this area and his blog is a must read for dealing with this scenario. You can read about his modifications to the Object Container Data Source here.


Pradeep also took the time to replace the dependency injection technique supplied by WCSF. Out of the box, WCSF for VS 2008 utilized ObjectBuilder. He replaced it with the newer P&P solution. He found using Unity for DI to not be a performance bottleneck, but application startup was slow. Another problem he encountered was that the team's project would often crash within the visual studio editor when under design view.

Wednesday, June 23, 2010

dealing with EF error

I have been spending a lot of time lately comparing NHibernate with Entity Framework using POCOs. I have been hesitant to blog about potential flaws in the EF because there hasn’t been a lot of writing out there on the subject. One experience I have had shows the holes in what is essentially a 1.0 for POCO support. The mapping error handling in EF must be improved.
If you make a mistake in EF where your class doesn’t map correctly to the model, you are likely to see this error “Mapping and metadata information could not be found for EntityType 'YourNamespace.YourClass'. When not using POCOs with EF, the properties in the class that map to the model are automatically generated. However, with POCOs you are on your own. For troubleshooting I did find it helpful to temporarily turn code generation of classes on and then compare my properties with those generated by the EF templates. It still is error handling that sucks, and it should be improved by Microsoft’s EF team. Ideally, the missing or mistyped property should be spelled out. In fact, when using EF with EntityClasses I received at one point (after mucking around in the model .edmx xml file) this error “The type 'Employee'('EntityType') of the member 'manager' in the conceptual type 'HelloEfModel.Employee' doesn't match with the type 'collection[HelloNHibernate.Employee(Nullable=True,DefaultValue=)]'('CollectionType') of the member 'manager' on the object side type 'HelloNHibernate.Employee'.” That is exactly the kind of error I want to see!