DataContext Represents the Database

1. Notice that the code contains classes named TasksDataContext and TasksList. The TasksDataContext class represents the database, and the TasksList class represents the database table.
   
   http://msdn.microsoft.com/en-us/library/bb470374(v=VS.90).aspx

Active Record vs. Domain Model

How do you devise your classes? Which capabilities should they feature? In particular, should your classes be aware of the database? Should they include logic (that is, methods) or be limited to just exposing properties? There are two main patterns you can refer to: Active Record and Domain Model.
In the Active Record pattern, your classes are closely modeled after database tables. You mostly have one class per table and one property per column. More importantly, classes are responsible for their own persistence and their own simple, minimal domain logic.
According to the Domain Model pattern, your classes are aimed at providing a conceptual view of the problem’s domain. These classes have no relationships with the database and have both properties and methods. Finally, these classes aren’t responsible for their own persistence. If you opt for a Domain Model approach, persistence has to be delegated to a distinct layer—the DAL. You can write this layer yourself, but it wouldn’t be much fun. A well-done DAL for a library designed according to the Domain Model pattern is nearly the same as an ORM tool. So why not use one of the existing ORM tools?

 http://msdn.microsoft.com/en-us/magazine/hh456393.aspx

Domain Model (DDD) vs. "Entity Model"

In the scope of this article, I’m not using the meaning that results from the Domain-Driven Design (DDD) methodology. For me, here, the domain model is simply the object model you persist—entity model might be another equivalent—and less confusing—term.

 http://msdn.microsoft.com/en-us/magazine/hh456393.aspx

Benefit of Published APIs

You definitely can create your own solutions for all these problems, but there are a lot of benefits to using applications with published APIs. One of the main benefits is that many developers know and understand what these APIs are and how they work. If you need to augment your staff, for instance, you can hire a consultant that is already familiar with these well-documented APIs. If you write your own, guess what; you also get to pay that person to learn your proprietary system.

http://msdn.microsoft.com/en-us/library/ms972319.aspx

Data Access Methods Change Frequently

Data access changes frequently.  Historically, the industry has modified data access techniques at least every three years; therefore, we can count on needing to modify data access three years from now for any healthy, long-lived systems that's mission-critical to the business.

 http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

Dependency Lookup v Dependency Injection

So what should you choose, Dependency Lookup or DI? If you use Dependency Lookup, there are hard dependencies on the framework that you use or the factories that must be created. It becomes larger amount of "glue code" and the code is not as easy to test. Therefore, DI used if possible.

Dependency Lookup or Dependency Injection

Enums and Booleans are Evil

[Y]ou need to be very careful with exposing state that is used for decision making in your code. It can be very easy to end up with a mass of untracked dependencies.

Enums are Evil: The State Pattern

Role Interface

The strength of a role interface is that it clearly communicates the actual collaboration between an activity and its successors. Often a class doesn't use all the methods of a class, so it's good to show which ones are actually needed. This can be particularly useful if you need to substitute it later on. A header interface forces you to implement every method, even if you're not going to need them; but with a role interface you only need to implement exactly what's needed.

http://martinfowler.com/bliki/RoleInterface.html

Leaky Abstractions Paradox

And all this means that paradoxically, even as we have higher and higher level programming tools with better and better abstractions, becoming a proficient programmer is getting harder and harder.

http://www.joelonsoftware.com/articles/LeakyAbstractions.html

Aggregate Roots vs Entities vs Value Objects

Entities can hold references to any Aggregate Root, but never to any other Entity or VO within theAggregate. To access any other part of the Aggregate, you must navigate from the Aggregate Root.

http://devlicio.us/blogs/casey/archive/2009/02/16/ddd-aggregates-and-aggregate-roots.aspx

RDMS vs OOP Data Protection

RDBMS tend to use rule-based and role-based protection and security mechanisms instead of direct interface restrictions. It could be said that OOP encapsulation uses "additive" security and protection control mechanisms; while RDBMS tend to use "subtractive" mechanisms.

http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch

LINQ vs DTOs

Commercial ORMs contain a rich set of features for dealing with the object-relational impedance mismatch. LINQ to SQL tracks changes to object state and converts queries composed using LINQ into native SQL. Populating and returning DTOs from the results of a query executed through ADO.NET is just a different method of transfer from returning datasets

pmarflee
http://stackoverflow.com/questions/817733/using-asp-net-mvc-without-an-orm

Helper Classes and SRP/DRY

The single responsibility principle sometimes drives the creation of helper classes as inclusion of their functionality could leave the core class with multiple responsibilties. Helper classes may also be created to stick with the DRY Principle (Do not Repeat Yourself); i.e. a piece of code that somehow seems to appear in all sorts of places needs to be consolidated in one place but doesn't have a natural home (though one should use this case very sparingly - it's more likely that you don't yet fully comprehend what's going on in your object model).

Peer Reynders
http://www.coderanch.com/t/100578/patterns/helper-functions-good-design

Use Interfaces and Small Classes - Seemann

Lots of small classes sounds just fine :)

Particularly if you let each class implement an interface and have the different collaborators communicate through those interfaces instead of directly with each other, you should be able to achieve a so-called Supple Design (a term from Domain-Driven Design) with lots of loose coupling.

Mark Seemann

http://stackoverflow.com/questions/1963991/srp-and-a-lot-of-classes

An Anti-Pattern Criterion: Requires too much Brain Power

The problem with using a Service Locator isn’t that you take a dependency on a particular Service Locator implementation (although that may be a problem as well), but that it’s a bona-fide anti-pattern. It will give consumers of your API a horrible developer experience, and it will make your life as a maintenance developer worse because you will need to use considerable amounts of brain power to grasp the implications of every change you make.

http://blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx

Documentation is "Icky"

At least in the context of DI. Take it from Mark Seemann:

By perusing the source code (or using Reflector) or consulting the documentation (ick!) we may finally discover that we need to register an IOrderValidator instance with Locator (a completely unrelated static class) before this will work.

http://blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx

C is Faster

[M]any CGI programs are still written in C, and they work faster and better than any true scripting language.

Ajax - The Definitive Guide (O'Reily, Holdener)