I recently have option to try Perforce source control system and I had to say that it's incredibly fast. It's faster than any other source control system for distributed development I ever gave a try.
Those of you who still don't use CruiseControl.NET
should hardly consider that. It is an automated Continuous Integration
server for .NET and it finally has support for CVS/VSS/Perforce/StarTeam/PVCS.
Recently my MSDN RSS feed announced me new version of .NET PetShop. The article tells us that PetShop was refactored for better architecture.
I was so curious, that I have downloaded PetShop installer and gave it a try. I am rather disappointed with its architecture. I am not telling that PetShop's architecture is bad. IMHO architecture can not be good or bad, but it may suite several requirements better or worse.
Current PetShop implements every type from conceptual model with the use of six classes from six projects (BLL, DALFactory, IDAL, Model, OracleDAL, SQLServerDAL).
I think you can estimate the cost of change in domain field. If you change one type, you will be obliged to change six classes.
You can also estimate the amount of work, which is required to add additional database layer. To add additional database you need to create NewDBDAL from the scratch, and you also need to extend DALFactory.
There are different ways to map relational data to objects. PetShop v3.0 is using Table Data Gateway. This at least doubles amount of classes, required to implement any domain field type. This is not good or bad, let's take it as a fact. How could we refactor current app and make it more extensible still using this pattern?
I would advise using Bridge pattern and implement DAL classes as one class instead of two classes and one abstract interface. This way we could separate DAL interfaces and algorithms from concrete database implementations. Later, when we decide to add support for additional DB we won't be rewriting DAL from the scratch we will just add additional implementation. We will also be able to reuse those implementations in our future projects, while current DAL has nothing to reuse if the project is not related with PetShop.
Another issue is BLL/Model. What's the benifit of splitting every class into two ones, one for behaviour and another for data?
Unit tests.... If this application is considered to be a good learning example, I think it should include unit tests at least for the business logic.
Don Box has recently posted link to Funkidator. This tool tells whether your blog is funky or not.
I tested several blogs with it and here is what I got.
Christian Nagel, Christian Weyer, Devin Rader, Julia Lerman and other blogs from weblogs.asp.net, which I have tested.
Not funky (they are still on my blogroll, not depending of funkidator) :
Clemens Vasters, MSDN RSS feed
I've come across this presentation
. Seems to be interesting.
I played with InfoPath 2003 beta 2 recently. It’s a new product from Microsoft Office System for creating forms, especially XML and web-services based forms.
Either I missed something or it does not support WSE and SOAP 1.2. That means InfoPath will hardly be integrated in Global XML Architecture (GXA).
From the other side, the product is really simple and that’s its strength. It has an easy-to-use intuitive interface which can be easily understood by business people.
I think I will use it as a RAD tool for creating UI to BizTalk services.
BTW, I’ve got BizTalk Server 2004 beta nearby, so I’ll definitely test it soon
MSDN has recently introduced RSS feed for their news. I was thinking about displaying that news on a first page of dotSITE Portal. During the implementation interesting idea came up to me. Those of you, who aggregates RSS feeds in their ASP.NET portal and still does not use cache, should consider doing that:
- It increases performance.
- What's more important it makes your app much more stable. There might be a case when your RSS provider will go down. If you are caching its feed you significantly decrease the probability of errors on your page.