Chad# - All Comments

re: C# 4.0 New features – Part 1: dynamic type

sandit27 — Tue, 14 Apr 2009 05:08:10 GMT

This is a good feature introduced in C# 4.0. The only issue I see is, the developer should not use the "dynamic" type leisurely . Special care should be taken when using the dynamic type.

-Sandeep

re: The more you know – Why List is bad with query results

Elio — Tue, 24 Mar 2009 18:25:54 GMT

Agree with Xtek, returning List<T> is bad almost always, in my entities i use this in my getters:

get { return new List<Report>(_reports).AsReadOnly()}

For me, it is inadmissible that the consumer of such entities can get direct access to the private member collection, even, for critical cases i just return a ReadOnlyCollection of DTOs:

get { return allReportDTOs()}

Where ReportDTO hav only primitive members

In fact, i'm using the DTOs way intensively today, because currently the UI guys are using a Presentation Model that get binded the entities properties collections to grids. Sure they can not Add/Remove items, but they can change the child properties directly from the GUI. That is a true problem, because many often those changes requieres some validation at the parent entity level.

Elio

Using interfaces for Domain entities (Part 1)

DotNetKicks.com — Thu, 12 Feb 2009 10:21:32 GMT

You've been kicked (a good thing) - Trackback from DotNetKicks.com

re: Using interfaces for Domain entities (Part 1)

MIke — Sat, 24 Jan 2009 03:05:36 GMT

When's part II coming? :)

re: Kigg – A great example of ASP.NET MVC

kazimanzurrashid — Wed, 21 Jan 2009 11:16:19 GMT

Hi Chad,

Just for an clarification, Sonu is not in DotNetShoutout team, he was part of the initial version of KiGG.

re: ADO.NET EF v LINQ to SQL (take 3)

EFRox — Fri, 16 Jan 2009 22:06:16 GMT

It does stink that you can't really work between contexts. I have instances where I'd like to write queries that join across contexts.

I'm working on a data migration project on a database that has tons of Identity primary key fields. Using the Entity Framework makes it really easy as all you do is associate it to the parent object and it handles assigning all the keys. Oh and its pretty easy to query on Primary Keys and Foreign Keys, just use the navigation/association in the model?

re: The more you know – Why List is bad with query results

Matt Freeman — Fri, 16 Jan 2009 13:45:21 GMT

Cant you use .Count(), I've favoured the IEnumerable route for a long time now and not encountered any issues, its encapsulate the type of collection should you ever refactor.

For Nhibernate mappings any IList is a private variable mapped by private field accessor, the IEnumerbale public route just get the list as IEnumerable. I dont want consumers adding to list or messing with it, the collection (not the items) should be immutable in that respect, they can always create a new List by passing the IEnumerable to the new List.

ADO.NET EF v LINQ to SQL (take 3)

DotNetKicks.com — Thu, 15 Jan 2009 18:55:40 GMT

You've been kicked (a good thing) - Trackback from DotNetKicks.com

ADO.NET EF v LINQ to SQL (take 3)

DotNetShoutout — Thu, 15 Jan 2009 18:52:42 GMT

Thank you for submitting this cool story - Trackback from DotNetShoutout

re: ADO.NET EF v LINQ to SQL (take 3)

Xtek — Thu, 15 Jan 2009 16:09:05 GMT

Yeah I have hops for v2 since the LINQ to SQL guys went over to that team... here's hoping.