Wednesday, April 13, 2011

SaveOptions in .net

SaveOptions.DetectChangesBeforeSave : this is the default. When you do ObjectContext.SaveChanges(), the method DetectChanges() is called to synchronized attach entities in the OSM.

SaveOptions.AcceptAllChangesAfterSave : When you do ObjectContext.SaveChanges(), the method AcceptAllChanges() is called - which is the guts of the OSM, where the entities in the graph are iterated, addresses and set to Unchanged/Detached.

SaveOptions.None : When you do ObjectContext.SaveChanges(), changes are saved immeditately - no synchronization at all. Whatever is in the graph is what will be saved.

In my experience i have not messed with this - i've left it as the default (DetectChangesBeforeSave).

Sometimes with POCO's i have heard you need to explicitly call DetectChanges, but i've never seen a recommendation/solution to change the SaveOptions to none.

Are you sure the solution in that question is to set SaveOptions to none? Maybe you should provide detail (or ask a seperate question) as to the error your getting, as a change like this will affect your entire persistence layer.

Tuesday, April 12, 2011

Agile and Waterfall differences

One of the most important differences between the agile and waterfall approaches is that waterfall features

distinct phases with checkpoints and deliverables at each phase, while agile methods have iterations rather

than phases. The output of each iteration is working code that can be used to evaluate and respond to

changing and evolving user requirements.
Waterfall assumes that it is possible to have perfect understanding of the requirements from the start. But

in software development, stakeholders often don’t know what they want and can’t articulate their requirements.

With waterfall, development rarely delivers what the customer wants even if it is what the customer asked for.

Agile methodologies embrace iterations. Small teams work together with stakeholders to define quick prototypes,

proof of concepts, or other visual means to describe the problem to be solved. The team defines the

requirements for the iteration, develops the code, and defines and runs integrated test scripts, and the users

verify the results. Verification occurs much earlier in the development process than it would

with waterfall, allowing stakeholders to fine-tune requirements while they’re still relatively easy to change.