 | | |
| | |
|
Spaces home  Hunt BlogProfileFriendsBlogMore |  Tools   |
Hunt Blogusing System.Hunt.Jason.Blog;
July 04 Language Feature Request: Smart method declarationsI haven't taken much of a look a the .NET Roadmap so I have a naive request: If I, now, don't have to declare the type when declaring the variable name when using var (C#) or Option Infer (VB.NET), it would be nice to also have return type assumed to be void (C#) or Sub (VB.NET) unless I specify otherwise. Original Syntax C# public void DoSomething() { ... } public int GetValue() { return 1; } VB.NET Public Sub DoSomething() End Sub Public Function GetValue() As Integer Return 1 End Function Proposed New Syntax C# public DoSomething() { ... } public int GetValue() { return 1; } VB.NET Public Method DoSomething() End Method Public Method GetValue() As Integer Return 1 End Method July 03 8 days before Canadians can get their iPhone 3G on There are a load of countries that will be having access to the new 3G iPhone come July 11th. As I understand it, Rogers is the exclusive carrier in Canada and have announced their price plans. Prices for the device are speculated to be CAD$199 for the 8GB and CAD$299 for the 16GB, with signing up for a 3 year contract. Since a friend of mine showed me his iPhone I have been drooling over getting myself one. The wait is nearly over! June 25 VB.NET is the Proverbial Red-Headed Step-Child of CLR Languages (alternate title: Things that make you think that Microsoft doesn't treat VB.NET as a first-order language) I've only started using VB.NET in the past year and a half on client projects. Prior to that it was always C#. I now consider myself fluently bi-lingual in either language as I make VB.NET syntax errors in my C# code as well as still making C# syntax errors in my VB.NET code. Since using VB.NET I've noticed that, though VB.NET is supposedly a "first order" language in the Microsoft stable, there are a few things that make that facade seem fairly thin:
I am sure the list is endless. These are just the top ones that stick in my mind at the moment. June 17 CLR Language Localization? It's struck me, since I have been working in VB.NET, that certain language semantics aren't translated properly across the different CLR languages. e.g. Assert.IsNotNull (C#) should be Assert.IsNotNothing (VB.NET). I am not certain how many of these semantics there are. Maybe it's something the languages teams could add into a future version of VS (please make it automagic with the option of setting an attribute). June 16 So... what's wrong with object.Validate()???Today I was asked why choose a validation framework over good ol' object.Validate(..) and given permission to publish the response. object.Validate is just fine except that the behavior doesn't serialize across the wire (it "will" if you re-instantiate the object on the other side if you are using a shared assembly, but won't if you are using object generated from the proxy in things like JSON, AJAX, or other client types what build their types from a WSDL or other schema. Often you will want the ability to do some validation on a client prior to firing it across the wire. Or... should the previous sentence read "firing it across to a long-running process"? More on this... One thing I have been thinking about, when it comes to object validation, was spawned by reading up on using enterprise service bus'. NServiceBus creator, Udi Dahan makes the distinction between "stateless services" like the classic calculator service and "statefull services", termed "sagas", which (and I hope I am close on this) can involve multiple domain objects but, more importantly, require state to complete their work. These 'sagas' are typically longer running, durable, transactionally processed messages that encapsulate business logic. My paraphrased definition for a statefull service likely does not do justice to the depth that is intended, but tie that binds the discussion of service purposing and validation is that there is often a struggle with how to do object validation in a re-usable (both sides of the wire) fashion. Validating that a type is not null or that it's value is a member of a natural number set is not something that requires state. Making a call to a value object validation service may be able to provide that point of re-use. It can be called from a client prior to calling one of those long-running sagas and your statefull service when doing its initial cleansing of the data it's receiving. Though that still incurs the cost of an additional network call (two if you consider that your statefull service will be calling the service as well), it frees those saga services from being bogged down with duplicated validation logic. This also enables you to use clients that can't share your assembly (JSON, JAVA, etc.) to utilize the stateless validation service. So, combining object validation frameworks with stateless services/services (SOA or otherwise)... there's my thoughts for today. *signing off*
|
|
|||||||||||||||||||||||||||||||
|
|
