It's not just me...

Link Here that thinks the coffee is complete shite in Britain.

More Linq to SQL pondering's

As has been noted on this blog before, I like the idea of Linq to SQL, but have some real reservations about it's use in an n-tier, real world way.

Rick Strahl has a good piece talking about the DataContext lifecycle. In a nutshell, the problem with the DataContext is that it is a persistent, connected object.

Most other ORM's use a static management object that you connect and disconnect as needed.

The issue with the Linq DataContext is knowing how/when to use it with your business layer. A single global DataContext is not a good idea as it doesn't allow enough flexibility in it's updating mechanism. The general consensus is to create a DataContext per Business Object, do its work and then dispose.

What this means in practice is you will end up having plain old C# objects being populated by Linq to SQL and passed between tiers using collections perhaps. You probably could pass IQueryable<T> objects between tiers, but this has it's disadvantages too.

So it's my conclusion that for real world, n-tier apps, Linq to SQL is far from the best approach, and in fact you shouldn't probably use it at all. I am going to stick to the collection based approach that I have always used, and maybe use Linq or Linq to SQL as purely a Data Layer and a nice querying language.

Unfortunately, from what I have seen from the Entity Framework has the same problems as Linq to SQL. Hopefully it's something Microsoft can remedy in the future. I think if they listen to the community they will have to.

C# Coding Standards

I was looking through some oldish code of mine the other day. While most of the code was ok, it was clear I wasn't working to any coding standard at the time.

Some variables are camel cased some Pascal. There were methods where the fields should have been and properties where the methods should have been. It wasn't a disaster, but it was a lot harder than finding stuff in my code these days.

Without wanting to get religious, I thought I would post my coding standard. I'm not arrogant enough to assume everyone will like it, but I think the point of the post is that it is important that some standard is adhered to, and everyone developing on that code knows it, and sticks to it.

I'm not going to go fully into every little feature, just the basics. There a couple of other documents on the net, and of course the "Bible" which I base a lot of my coding standards on.

Code Specifics

1) Private fields should start with the _

Example:

private int _classId;

2) Camel Casing.

All variables and parameters should be camel cased. Abbreviations should be camel cased unless 2 letters or under. Id is a special case and should be camel cased.

Examples:

private Node GetNextChild( Node startNode, Node currentNode)

private int _classId;

private string _memberITDepartmentName;

3) Pascal Casing

All Properties and Methods should be Pascal Cased.

Examples:

public string MemberName
{

get;
set;

}

public int GetMemberId(string memberName)

Code Layout

1) Brace Layout

All braces should be on their own line directly under the code they follow. This includes methods, control and looping statements.

Example:

private void UpdateAll()
{

for (int i = 0; i < 100; i++)
{
...
}

}
 

2) Indentation

All code should be indented where appropriate 4 spaces.

3) Regions

All code should be broken up into regions in this order

Constants, Fields, Constructor(s), Properties, Methods, Delegates, Events

Naming Conventions

1) Variable Naming

Developers are free to name variables as they see fit, but Hungarian notation should not be used, although if agreed upon, HN can be used when naming GUI elements, eg btnOK, btnClose.

Variables should not include the type name of that variable

Example:

private string _connectionString;

2) File Naming

File should be named of the type they are. Class files should start with cls, interfaces should start with I. Interface names should also start with a capital I, but class names should not include the cls.

I'll stop there. I think all the bases are covered, like I said before I think it is important each team has there own standards that are agreed upon and used, but these ones could be a good place to start...