I am badly waiting for RIA support on 4.1 model-first (LinqToEntitiesDomainContext<TContext> where TContext : DbContext - is's not supported yet).
Also, you shouldn't have to decorate your POCOs with the nasty Key attributes, the goal is to have generated POCOs that RIA processes and decorates automatically for the client (perhaps via DomainDescriptionProvider).
Anther thing I couldn't come along is how to share interface implementations over the wire, please vote for it.
My wet dream is model-first only, and this should generate database (should have more options), server entities, auto-decorated client DTOs that implement interfaces generated from POCOs (undecorated at all) + full MVVM support (i.e. relaxed while very extesible data manipulation controls for the VMs that can be (or not) exposed to the Views)
Hello Mike! I love your videos, I feel I got much wiser after watching this series.
I think it would be a great thing if you could add videos about the other features of Prism 4.0 (navigation etc.)
Also, I wish you could extend this series so that after watched and studied, user should be able to build a robust Silverlight LoB application, using other related features of Silverlight and its relatives, such as WCF RIA Services, Entity Framework, and patters like Repository, DAL and more. The final idea is to teach users how to create a real-life end-to-end LoB application using the most efficient available ways and technologies.
Take it easy brother, I just brought plain examples, forget about the specific data.
1) I would never use Dim integer = "45", I just meant that you don't need to explicitly convert anything, and yes, sometimes when you are sure that the String's value is actually an integer you don't have to pass it to another Parse function.
2) Enums in vb can be automatically used as plain integers so u can use it in some cases even to make some calculations and conditions according to the order of it, not only but I make the numbers in my enum according to the desired calculations I expect later,
u can even use bit shift if you have very large enums with key values so u make the key values 8 16 32 and use bit shift etc. again, I just brought you examples to explain what I said but the examples are not the code, so chill about it.
3-4) I don't; Instead I write comments on every line.
And no, don't learn from me, this is just my taste, and if you really want to hear, sometimes I could write
Dim x As Integer
If x Then
Console.WriteLine("x <> 0") 'Will never reach this line since x =
With the above example I mean 2 things, 1st, that integers can be evaluated as booleans, and 2nd, you can rely on the fact that integer is not nullable and bacomes automatically 0 when declaring the field.
Especially, this days that you can oficcially declare Dim x = 5 and the compiler automatically recognize it as integer and even provides full intellisense support.
I would agree with you concerning the readability issue, but I told you I am good with comments, besides I am not working with a group, so I am the one who decides about the coding conventions, and I do have strict conventions.
I would also say "Different strokes for different folks".
Personally, that's why I like VB, FLEXIBILITY!
Thanks for your post, would like further discussions
Actually I think that in Wpf when you bind data it's binded to properties only (I am not definately sure).
Donno if applying attributes on properties will work on private fields as well as exposing properties with BrowsableAttribute for the desiner in a custom control.
these examles should be checked i am not sure they're even relevant.
But as Jason said, properties became a convention of encapsulation...
Qoute: Ok, not having to use the line-continuation character is nice as well as the auto properties, but things like (multiline) lambas just make the code more difficult to read.
The same with 'anonymous types'...
Maybe it is because I haven't seen a good example where the features mentioned above are usefull.
When u will want to use long inline delegates you will have big pain on writing everything in 1 line.
letting VB go a bit out the box regarding lines, about the readability, again, you're wrong there is End Function made just for you!
And I would tell Jason Rock! great vid, waiting for more!
3.) I think that you always should explicit declare a variable and not write code like "Dim counter=5"
Are you sure?? sometimes I am sure about the result and I even write things relying on VB implicit:
Dim i As Integer = "45"
TextBox.ScrollBars = 3-2
TextBox.IsMultiLine = 5
I never had bugs with it and it's very useful, I would even tell u that this is one of the reasons I didn't leave VB after the un-implementing auto props flop in 2008 ver.
Oh, another cool example:
Sub Form_Load(sender As Form, e As EventArgs)
'now you have full intellisense, in cs you have to explicitly cast it.
But all this is in my humble opinion and experience I might be wrong.
Sub DoJob(str As String Where str.Length > 15) As Object
- or -
Sub DoJob(ec As EntityCollection(Of c As Contact Where c.FirstName.StartsWith("a")) Where ec.Count > 26)
I donno if the following 2 issues are in the right place anyway I think they're needed.
Dim tb As New TextBox
Dim prop As Boolean = tb.HasProperty("Text") 'HasProperty should be an extension method then I can use the above
Sub DoJob As Object Where Abc.HasProperty("asdf") (+ intellisense exposing that property, sorry for being rediculus lol)
I think it's about time to include these methods (HasProperty etc. in object and not wait for me to include all my extensions, it should be in .NET!).
Entities (in Entity Framework) should be able to inherit from external classes providing functionality to override, overload and shadow fields (as for now entities can only implement interfaces, this is a big issue because interfaces can't actually do anything)!!!
5) - continuation of the above
entity fields should be able to be custom types (providing an IEntityConverter etc. (just saying) interface).
Interface IEntityConverter(Of TSource, TTarget)
Function Convert() As TTarget
Function ConvertBack() As TSource
Structure Phone : Implements IEntityConverter(Of String, Phone)
Public ReadOnly Property Extension As String
Public ReadOnly Property AreaCode As String
Public Property Number As String
Public Sub New (phone As String)
Public Function Convert() As Phone Implements IEntityConverter(Of String, Phone).Convert
Public Function ConvertBack() As String Implements IEntityConverter(Of String, Phone).ConvertBack
Using data As New Entities
Dim p As Phone = (From c In data.Contacts Select c.Phone).First
notice that phone in the database is a plain string of course
same should be mapping to classes and interfaces
That's all I have for now (I have a lot but don't remember right now), I'd love to hear how fool (or not?) I am...