Free magazine for Dutch developers. I know it isn’t exactly aimed at the more experience .NET developers, but I'm sure you'll be able to find someone within your organization not familiar with some of the concepts discussed in this issue.
I know I should never look a gift horse in the mouth, but the candy on the Microsoft PDC site is to good to be let alone. That site is so god dam slow! My life would be so much more comfortable if the publishing system would be simple media files zipped, ready to be leeched.
ps: petit plan update
Yesterday “night” I watched the PDC presentation “Navigating the Data Access Maze” by Alex Laskos, Dinesh Kulkarni, Michael Pizzo which was unfortunately of less quality due to technical problems with the demo material. Besides that it was really informative about when to use what. A question that pops up in my head on a daily basis (I know this isn’t normal behavior). This morning I watched the PDC presentation “Developing Applications Using ADO.NET ObjectSpaces” by Luca Bolognese. I find this the best presentation I’ve seen for as far as I can remember simply (besides my own presentations of course) because of the fun factor Luca introduces. Well done Luca! (and by the way Luca, please consider to start blogging )
One of the things I like about ObjectSpaces is the ObjectReader concept. I dislike most of the object relational mapping frameworks because of the lack of control on your queries. The ObjectReader promises just that, which is great to hear. As usual it all comes with a price which in this case is extra code to write and maintain besides the extra complexity introduced. I noticed my own object relational mapping framework gained a lot of performance by rethinking the data access strategy and optimize retrieval scenarios 1:1 to how entity objects are actually used. I realize that this isn’t common for large business frameworks but very welcome for relatively small apps which eventually could increase user satisfactory a lot.
I’m very excited to see Microsoft technology move towards solid Domain Models patterns. Next pres up is MBF related :)
Yesterday I picked up on Paul & David’s new title “Programming the .NET Compact Framework in C#”. In appendix A they give a few arguments for using Hungarian naming conventions throughout their book. I can remember myself advising Frans to stop generating code using Hungarian notation during the development of LLBLGen. Why did we stop using Hungarian? Only because of Microsoft’s recommendation to use Pascal/Camel? What do you and your team use and why?
Q: In conclusion, what can you suggest to our readers about building effective Remoting applications?
Don’t use SoapSuds. Define interface and access your remote components based on these interfaces. If you need 100% scalability, use SingleCall SAOs, and avoid CAOs and events. Host in IIS with the binary formatter to provide for the best match in security, scalability and performance.
Read the full article here. It seems Ingo spends about the same amount of time on his work as I do... and I always thought I'm the only geek around here ;)
Jimmy expressed his concern regarding (although based on rumors) “lazy loading” being decided at compile time. More on that later. Frans suggested I’d check out how “lazy loading” is implemented, so I decided to do so and share my findings.
ObjectsSpaces defines the loading of associations, typed one-to-many and one-to-one only by explicit request as “Delayed Loading”. In our world we tend to call this behavior lazy loading but as can be in found in the SDK… the marketing department thought “delayed” would be more appropriate (you would say those guys have better things to do).
Delayed Loading is provided in the ObjectSpaces namespace via two objects: ObjectList and ObjectHolder (hmm…). The ObjectList is intended for one-to-many relationships whereas the ObjectHolder for one-to-one. In case you noticed, these objects are wrappers, weak typed actually (hmm…).
The scenario:
We want to load a customer. This customer is named “Paul” and has an unhealthy amount of tech books. We have no reason to communicate the books to our end user. This specific end user is only interested in my mail address to spam me (Yes it’s getting more worse every day). We decided to not load the books because we are lazy! Err, we decided to load these books some other time so it’s valid to call this behavior “delayed” (Notice “delayed” is just plain weird? We have no interest in loading them at all). Our code could be looking like this:
using System.Data.ObjectSpaces;
public class Customer {
public ObjectList Books = new ObjectList();
}
I wipe away a tear while looking at that code. We live in a typed world! Luckily the ObjectSpaces team provided a solution.
public class Customer {
private ObjectList _books = new ObjectList();
public BookCollection Books {
get {
return _books.InnerList as BookCollection;
}
set {
_books.InnerBooks = value;
}
}
}
Ok, so returning a specific cast of the InnerList collection is the solution.
Yes Jimmy lazy loading is to be decided upfront. Though the users of my OR-mapper never requested for this additional functionality, I can imagine you could make good use of it, but how would you implement this? Would it be worth the effort? Frans, this programming model isn’t nearly as sophisticated as LLBLGen Pro provides, but you need to understand that without code generation this is the way to go. No it’s not… letting your typed collections inheriting these ObjectSpace collection objects would be my first choice.
On a side note, the mapping file expect a Lazy Loading attribute… ROFL
<osd:Member Name="_books" Alias="Books" LazyLoad="true" />
I’m intrigued with ObjectSpaces.
I really like the OPath concept. Explicit declaration of additional OPath queries object scheme based and pre-compilation of the actual mapping scheme. What a joy to see this integrated in ADO.NET right on top of the data providers. I am aware of the fact OS isn’t nearly as feature complete as the first generation of commercial OR-mappers but I consider it to early to make any assumptions regarding OS’s future box content. One thing is for sure… choosing Microsoft technology would be my first choice over third party products due to the tight integration in the .NET Framework.