James 的个人资料James's Space照片日志网络更多  |  工具 帮助 |
|
11月24日 BDC is not SO (I think)I was having a small debate recently about whether BDC (Business Data Catalog in MOSS - SharePoint 2007) can be considered part of a SOA... he mentioned BDC as being related to SOA and something inside me kind of twinged in response. To me, BDC breaks various SO concepts and implies a tight dependency between the integration with SharePoint and the implementation of the line of business app.
If you retrieve directly from a database using BDC, then obviously the integration is tightly coupled to the line of business application implementation + there's no service, obviously not SO. On the other hand, even if you retrieve the information from a Web Service, what I've seen of the way in which BDC is implemented suggests to me that you would normally end up having to write the Web Service in a way that directly exposes information about the implementation of the application, and that is designed to support SharePoint's use of BDC. So this seems to me to be not autonomous nor, again, loosely coupled. This doesn't surprise me though given what BDC is designed to achieve. It's one integration mechanism designed for a particular set of SharePoint functionality - hence you will end up writing web services purely to support BDC. Nothign wrong with that, it just doesn't seem SO to me.
But maybe I'm wrong or need to look at the web services support more closely. Anyone want to comment? 11月22日 Updated Trinity.XsltxI've updated my Trinity.Xsltx framework, primarily to fix a few bugs. Other changes:
The updated version is available at the same link as before, at http://www.tesl.com/NR/rdonlyres/10DFD5E6-2D28-4F8B-A468-AA71E85A1684/0/TrinityXsltx.zip. 11月17日 Exception HandlingException handling is an interesting topic... even though the topic has been known about by most OO developers for 10-15+ years, and most MS developers have been using it now in some form for 5 years, I always seem to end up reviewing code with excessive or inappropriate exception handling and that happened to me again recently.
Personally I like this article: http://www.codeproject.com/dotnet/exceptionbestpractices.asp which I think is fairly complete and easy to understand. FxCop also does a reasonable job of picking up some common exception handling misuse (e.g. 'catch (Exception ex) {...}') so keep that turned on to remind you when you are being lazy :).
One thing I think people often do badly beyond the core practices mentioned in that article is making decisions on where to put exception handling in scenarios such as reusable class libraries, and/or with respect to the different tiers in an n-tier application. A common decision that I think is wrong in most cases, and certainly wrong as a principle to apply to all .NET development, is that 'all public methods should have exception handling', the factors driving the decision this week
 being that each component should be treated as autonomous and hence considered independently. Hence for that component, its public interface was the system boundary so if no exception handling happened there, that component 'wasn't doing exception handling' and hence would be a 'bad component'. I think this is very obviously flawed but I've seen this reasoning before.It boils down to the basic principle of "don't handle exceptions unless you can do something about them to enable the system to behave as expected" - which of course also means that user interfaces should tell the user if they are unable to do as requested, rather than just sit there and pretend nothing has happened (hide the problem) or totally fall over (meaningless error messages and terrified users). A way I like to think of it is that normally, unless you can recover transparently to the caller (e.g. wait for the database cluster to fail over and then reconnect/re-run the transaction as if nothing has happened), you shouldn't handle exceptions - i.e. only code that understands the overall context of its use, input and output as relevant to the complete solution should handle exceptions and log/report them. In general it means that class libraries should never implement exception handling and that user interfaces and (typically web) services written with SO in mind should always implement some form of exception handling. Have I said that wrong? If so tell me
... but hopefully you can see what I mean. This is all really a corollary of the principles and recommendations espoused in that article but I think that's useful in helping people better understand how to apply them.When these decisions about where to handle exceptions are made wrongly, then they often go hand in hand with other bad practice, such as not re-throwing exceptions and instead returning empty collections / empty XML etc. Obviously that would mean that calling code (and therefore end-users of the system) would potentially be unable to distinguish between no data being stored / available and a fundamental system malfunction such as a database being offline. This kind of thing is however sufficiently covered by the article above, so I'm not going to discuss those in any more depth... READ THAT ARTICLE .EVO platform appears bit by bit...In case not everyone's already noticed, many of the core components of the new releases of Exchange, Vista and Office ('EVO') are now becoming available:
11月5日 Fascinating article on manufacturing and agile processesToday I came across a link on Martin Fowlers site to the text of a talk by Enrico Zaninotto, an economics professor, discussing the differences and similarities between what happened in manufacturing to improve their processes, and what's been happening lately with the shift from waterfall to agile processes. As Martin Fowler points out this has been discussed before by Mary Poppendieck, but this adds additional insights to that same topic. Very interesting...
|
). I might also need to consider signing the serialised data and may just (for DataBindAndRender anyway) move it into the viewstate... more thought needed by me here.|
|
