LINQ for SQL

LINQ for SQL unit testing Part2

Ben Kloosterman — Wed, 14 Jan 2009 16:38:38 GMT

I'm not really sure whether the benefits are worth it unless you need very high quality code and for larger applications. I'm not sure why i feel this and whether this is due to compartmentalizing the LINQ code or whether its just TDD on LINQ code which can be tested via a test DB i suspect its the TDD.

Still storing all the sql in the various repositories is a plus.

}

---------------------------------------------------------------------------------------------------------------------------internal class ProvinceRepositry : RepositryBase<Province>, IProvinceRepositry{public ProvinceRepositry()base(new ProvinceUnitOfWork())public ProvinceRepositry(IUnitOfWork<Province> work)base(work)#region IProvinceRepositry Memberspublic ProvinceCollection GetWorld(string worldname)throw new System.NotImplementedException();public ProvinceCollection GetWorld()throw new System.NotImplementedException();public Province Get(int id)throw new System.NotImplementedException();public void Update(Province prov)Guard.ArgumentNotNull(prov, "PROVINCE"); public void Create(Province prov)Guard.ArgumentNotNull(prov, "PROVINCE"); throw new System.NotImplementedException();

{

}

{

}

{

}

{

}

{

}

{

}

{

}

#endregion

}

-------------------------------------------------------------------------------------------------------------------------

{

}

#region

{

context.SubmitChanges();

}

#endregion

#region

{

context.Dispose();

}

#endregion

}

internal class ProvinceUnitOfWork :UnitOfWorkBase<Province>, IUnitOfWork<Province>DataContext context;public ProvinceUnitOfWork()this.context = DataContextFactory<DataClassesDataContext>.GetThreadScopedDataContext(); ; IUnitofWork<World> Memberspublic override bool ReadOnly { get { return !context.ObjectTrackingEnabled; } set { context.ObjectTrackingEnabled = !value; } }public override void SubmitChanges() IDisposable Memberspublic override void Dispose()internal interface IProvinceRepositry{ProvinceCollection GetWorld(string worldname);ProvinceCollection GetWorld();Province Get(int id);void Update(Province prov);void Create(Province prov);

LINQ for SQL unit testing Part1

Ben Kloosterman — Wed, 14 Jan 2009 16:25:59 GMT

Ian Cooper had some nice articles on how to do unit testing , i have implemented his code and ideas ( shown below) .

See Part 2 for some Business code

{

impl = source;

queryableImpl = impl.AsQueryable();

}

{

}

{

impl.Add(item);

queryableImpl = impl.AsQueryable();

}

{

}

#region

{

}

{

impl.Remove(item);

queryableImpl = impl.AsQueryable();

}

{

impl.RemoveAll(MatchWithContainer);

queryableImpl = impl.AsQueryable();

}

{

}

#endregion

#region

System.Collections.

{

}

#endregion

#region

{

}

{

}

{

}

#endregion

}

public interface IDataSource<T> : IQueryable<T>, IEnumerable<T>,ITable, IQueryProvider

{

}

{

}

public

{

}

interface IUnitOfWork<T> :IDisposableILINQDataSource<T> DataSource{ get; set; } //table// bool ReadOnly { get; set; }void SubmitChanges(); // only call for inserts OR when all work is done

{

unitOfWork = work;

}

{

#region

{

}

{

dataSource =

}

#region

public abstract class UnitOfWorkBase<T> : IUnitOfWork<T>ILINQDataSource<T> dataSource; IUnitofWork<T> Memberspublic ILINQDataSource<T> DataSourcegetreturn dataSource;setvalue ;abstract public bool ReadOnly { get; set; }abstract public void SubmitChanges();#endregion IDisposable Membersabstract public void Dispose();#endregion}public class RepositryBase<T> where T : classprotected IUnitOfWork<T> unitOfWork;public RepositryBase(IUnitOfWork<T> work) Guard.ArgumentNotNull(work, "work");//public IQueryable<T> T//{// get { return gameSettings; }// set { gameSettings = value; }//} }public interface ILINQDataSource<T> : IQueryable<T>, IEnumerable<T> void Add(T item);void Attach(T item);void Remove(T item);void RemoveAll(IEnumerable<T> items);

publicclassMemoryDataSource<T> : ILINQDataSource<T> List<T> impl;IQueryable<T> queryableImpl;public MemoryDataSource(List<T> source)public MemoryDataSource(): this(newList<T>())publicvoid Add(T item)//public IQueryable<S> CreateQuery<S>(Expression expression)//{// return queryableImpl..CreateQuery<S>(expression);//}IEnumerator<T> IEnumerable<T>.GetEnumerator()return impl.GetEnumerator(); ITable<T> Memberspublicvoid Attach(T item)return; publicvoid Remove(T item)publicvoid RemoveAll(IEnumerable<T> items)internalbool MatchWithContainer(T item)return impl.Contains(item); IEnumerable MembersIEnumerator System.Collections.IEnumerable.GetEnumerator()return impl.GetEnumerator(); IQueryable Memberspublic System.Type ElementTypeget { return queryableImpl.ElementType; }publicExpression Expressionget { return queryableImpl.Expression; }publicIQueryProvider Providerget { return queryableImpl.Provider; }

LINQ for SQL thread affinity Data context

Ben Kloosterman — Wed, 14 Jan 2009 16:01:21 GMT

From http://www.cnblogs.com/sunrack/articles/1130866.html , for services we use mainly Thread Context ( the original allows a static context as well ).

Thread context is very usefull for services.

{

TDataContext result = (TDataContext)

SetOptions(result);

}

{

TDataContext result = (TDataContext)

SetOptions(result);

}

{

options.LoadWith<

context.LoadOptions = options;

}

{

}

{

}

{

key =

context =

{

context = GetDataContext();

context = GetDataContext(ConnectionString);

{

threadData =

}

{

}

{

}

{

}

///<summary>/// This class provides several static methods for loading DataContext objects /// in a variety of ways. You can load the data context as normal one new instance/// at a time, or you can choose to use one of the scoped factory methods that/// can scope the DataContext to a WebRequest or a Thread context (in a WinForm app/// for example)./// /// Using scoped variants can be more efficient in some scenarios and allows passing/// a DataContext across multiple otherwise unrelated components so that the change/// context can be shared. ///</summary>publicclassDataContextFactory<TDataContext> where TDataContext : DataContext, new()///<summary>/// Creates a new Data Context for a specific DataContext type with a connection string/// /// Provided merely for compleness sake here - same as new YourDataContext()///</summary>///<typeparam name="TDataContext"></typeparam>///<param name="connectionString"></param>///<returns></returns>publicstatic TDataContext GetDataContext(string connectionString)Type t = typeof(TDataContext);Activator.CreateInstance(t, connectionString);return result; ///<summary>/// Creates a new Data Context for a specific DataContext type/// /// Provided merely for compleness sake here - same as new YourDataContext()publicstatic TDataContext GetDataContext()Type t = typeof(TDataContext);Activator.CreateInstance(t);return result; publicstaticvoid SetOptions(TDataContext context)DataLoadOptions options = newDataLoadOptions();Force>(Force => Force.Characters); //add more rows///<summary>/// Creates a Thread Scoped DataContext object that can be reused./// The DataContext is stored in Thread local storage.///</summary>///<typeparam name="TDataContext"></typeparam>///<param name="key"></param>///<returns></returns>publicstatic TDataContext GetThreadScopedDataContext()return (TDataContext)GetThreadScopedDataContextInternal(null, null);///<summary>/// Creates a Thread Scoped DataContext object that can be reused./// The DataContext is stored in Thread local storage.///</summary>///<typeparam name="TDataContext"></typeparam>///<param name="key"></param>///<returns></returns>publicstatic TDataContext GetThreadScopedDataContext(string key)return (TDataContext)GetThreadScopedDataContextInternal(key, null);///<summary>/// Creates a Thread Scoped DataContext object that can be reused./// The DataContext is stored in Thread local storage.///</summary>///<typeparam name="TDataContext"></typeparam>///<param name="key"></param>///<returns></returns>staticobject GetThreadScopedDataContextInternal( string key, string ConnectionString)if (key == null)"__WRSCDC_" + Thread.CurrentContext.ContextID.ToString();LocalDataStoreSlot threadData = Thread.GetNamedDataSlot(key);object context = null;if (threadData != null)Thread.GetData(threadData);if (context == null)if (ConnectionString == null)elseif (context != null)if (threadData == null)Thread.AllocateNamedDataSlot(key);Thread.SetData(threadData, context);return context;///<summary>/// Returns either Web Request scoped DataContext or a Thread scoped/// request object if not running a Web request (ie. HttpContext.Current)/// is not available.///</summary>///<typeparam name="TDataContext"></typeparam>///<param name="key"></param>///<param name="ConnectionString"></param>///<returns></returns>publicstatic TDataContext GetScopedDataContext(string key, string connectionString)//if (HttpContext.Current != null)// return (TDataContext)GetWebRequestScopedDataContextInternal(typeof(TDataContext), key, connectionString);return (TDataContext)GetThreadScopedDataContextInternal( key, connectionString);///<summary>/// Returns either Web Request scoped DataContext or a Thread scoped/// request object if not running a Web request (ie. HttpContext.Current)/// is not available.///</summary>///<typeparam name="TDataContext"></typeparam>///<param name="key"></param>///<returns></returns>publicstatic TDataContext GetScopedDataContext(string key)//if (HttpContext.Current != null)// return (TDataContext)GetWebRequestScopedDataContextInternal(typeof(TDataContext), key, null);return (TDataContext)GetThreadScopedDataContextInternal( key, null);///<summary>/// Returns either Web Request scoped DataContext or a Thread scoped/// request object if not running a Web request (ie. HttpContext.Current)/// is not available.///</summary>///<typeparam name="TDataContext"></typeparam>///<param name="key"></param>///<returns></returns>publicstatic TDataContext GetScopedDataContext()//if (HttpContext.Current != null)// return (TDataContext)GetWebRequestScopedDataContextInternal(typeof(TDataContext), null, null);return (TDataContext)GetThreadScopedDataContextInternal( null, null);

OO with services

Ben Kloosterman — Wed, 14 Jan 2009 15:33:15 GMT

Are OO code and SOA diametrically opposed ? In a lot of ways this is true services tend to produce very anemic object models however this merely reduces reuse which is a myth in OO for the majority anyway .

However services have a unique but familiar problem . The contract of the service is critical it needs to be designed for

- The ease of use of the client

- For performance ( ie chunky calls , many small calls can bring many services down to its needs)

- To be upgradeable and allow backward compatibility.

- Compatible with an XML schema ( eg generics and interfaces create problems)

- Best to be compatible with WS standards and non Windows Communication Foundation clients ( eg nullable datetime , no char , long etc )

- Only sub object and collections needed for this call need to be propagated which is not all the objects and collections a object may contain. eg Order GetOrder(..) may contain OrderItems which contain Products but no more information about the product such as supplier etc . This is best described as truncated trees.

( see how to write a good contract)

This is dramatically different from an OO structure where ease of use is not high on the list else we would all be using statics , however its very similar to a relational database and its structure.

Does this mean services are similar to databases ( eg Procedural Programming) ? From the outside yes and smaller services probably should remain Procedural and non OO . (A good example is in the LINQ and services article)

However larger services should retain a significant OO core with a focus on code quality , testability and maintainability however this requires a reverse ORM which maps from the messages to the internal logic. Microsofts P&P Web service factory includes converterts exactly for this purposes and its a good pattern to follow.

Even in small services when mapping from a DB to messages there is a case for such a conversion layer ( and DTOs) . Take the case of LINQ for sql if you add a member to a DB table for some new functionality meant to be visible to a select group do you want every client to now have this information in the data sent down ? If custom message contracts were used only the new operation and contract used by the select group would get the new information however all the logic would be common ( just the privileged data would not be copied to contract) . If custom message contracts are not used the team would be forced to create a new schema copy of the data for the same table which would be identical except for the one member as can be seen over time this would reduce maintainability of the service .

How to write a good service contracts

Ben Kloosterman — Wed, 14 Jan 2009 15:10:47 GMT

... not hand craft wsdl

Custom messages reduce churn and change in the contract

Lets say you have this datacontract

[DataContract]

public class WorkEntry

{

[DataMember]

public DateTime StartTime;

[DataMember]

public TimeSpan Duration;

[DataMember]

public string User;

[DataMember]

public string CostCentre;

[DataMember]

string Comments;

}

What can go wrong here ? Using public fields is good , its tight and if you need to do custom things you can refactor it easily. I think there is nothing really wrong here however if this is a business object also i would be concerned.

The big gotcha maybe DateTime , lets say you have some other systems in your company that use Java . Now Java systems use a nullable DateTime and can send null ( and DateTime.Min can become null if emit default values is false) causing all sorts of issues . Management decides YOU must change however you have used this as a business object through your app . You can change the DateTime to DateTime? However there are a large amount of implication to your application in now having to deal with possible null values - including the SQL server and DB and hence what is a trivial change requires pretty a lot of work and risk and hence testing ( note TDD or unit testing here do not help and make it worse as the unit tests also have to change) .

The problem here comes from using your DTO ( data transfer object eg message /DataContract) as your business object. I think this should be avoided in all cases where the service is non trivial. In Trivial services its easy enough to write a new service or make the changes and hence using the business object as the message is ok.

Avoid .NET specifics especially

non int integer types
char
generics ( not that it works)
serializing interfaces
inheritance

Ultimately messages are serialized as XML and forcing a object model onto it will always result in difficulties and leaky abstractions for the domain. The solution is simple DONT let WCF and your communications contaminate your object models use the DTO(Data Transfer) pattern.

see DTO pattern.

LINQ for SQL and reattaching objects in nTier scenarios

Ben Kloosterman — Wed, 14 Jan 2009 15:00:23 GMT

One of the issues that keeps cropping up is LINQ for SQLs support for nTier scenarios and having to reattach the object to the DataContext.

However this problem is exhibited by all ORMs in nTier scenarios ( though not in web sites) and you basically have 2 choices

- refetch the object from cache/DB and replay all changes to see what has changed then you can craft a custom Update to just change the items changed.

- update all fields in the DB.

While the 2nd method is easier the first is more efficient especially when you consider that it is very likely that the object is still in a cache.

In both cases a row version/timestamp is normally required for concurrency .

ProcessOrder ( Order order)

{

var orderDB = ThreadDataContext.Context; //get dataContext
//Products is the table we draged and dropped in the dbml designer
var _oldOrder = (from _orders in order.Orders

select _order where _order.id = order.id).Single();

//note as you have the old order and new order you can apply some logic , this is much more efficient than doing it in a db

if ( _oldOrder.IsFinalized())

throw new InvalidOperationException("Finalized order cant be changed");

if ( _OldOrder.RowVer != _order.RowVer)

throw new ConcurrencyException("Order already Changed") ;

//update the fields

_oldOrder .Number = order.Number;
_oldOrder .CustomerId = order.CustomerId;

// etc ...

new BLL.OrderProcessor().Process(_oldOrder); //process

}

You could use reflection to automate the copying and then the new order would just overwrite the previous order but this has 2 issues

It would be slow
It would allow the client to trash the servers object by serializing on top of it .

It is also worth noting for medium and large services you are likely to have an internal object module and code to convert from messages to internal code anyway ( see OO with services article)

I think fetching the old order is good business practice anyway and stops issues like a client bug updatting a service and trashing a fulfilled order with a new one . Fetching the old order allows you to uphold one of the SOA tennats/rules that a service should never trust a client .

It is worth noting the same thing needs to be done for member objects or collections and hence its usefull to provide some simple converter classes for each type . The result of this is that services ( that write to a DB) using an ORM tend to have an external message structure different from the internal OO representation even when the OO model and service is quite small. Even though this is a burden it does not introduce a lot of time or any complexity and is a good practice to follow for all but the smallest services anyway. ( Again see OO with services article)

Is LINQ for sql dead

Ben Kloosterman — Wed, 14 Jan 2009 14:17:24 GMT

There were a lot of comments about the supposed demise of LINQ for SQL people expected it to evolve into a nHibernate style framework (and rightly object to EF Entity Frameworks change tracking http://weblogs.asp.net/fbouma/archive/2008/11/21/baby-sitter-framework-2-0-change-tracking-in-the-ef-v2-it-s-still-your-problem.aspx ) .

I think people miss the point here , LINQ for SQL is and always will be a light weight solution for smaller or RAD style projects. As Damian Guard ( from the LINQ for SQL team ) explains it will be maintained and changes required by the community will be implemented. http://damieng.com/blog/2008/10/31/linq-to-sql-next-steps. As it is now it is fine for most current and future needs.

I admit this leaves some people in the hole ( especially large scale OO apps) however EF and nHibernate will duke this out. I have used nHibernate before and personally i dont think the complexity is worth the benefits , I spent a lot of times solving nHibernate problems rather than business or even architectural or software design prolems and i also had an issue with the way it handles sessions if you have lots of small stateless calls ( eg web services) it tends to be quite heavy. For EF (Entity Framework) the jury is out and i will see how it evolves.

Are Datasets dead

Ben Kloosterman — Wed, 14 Jan 2009 14:01:45 GMT

Can anyone see a use for Datasets these days ? LINQ for SQL seems to have all the bases covered with a much easier and extensible model.

Performance

Performance varies dramatically for simpler queries and updates LINQ2SQL seems to have it , but for more complex queries datasets have an edge . Complex reports are better in datasets but the time for reports to complete is not that relevant as they don't execute so often.

Here are some benchmarks

http://www.codeproject.com/KB/database/linqVsADO.aspx provides a simple query result and shows simple retrieval.

http://visualstudiomagazine.com/features/article.aspx?editorialsid=2372 provides a more complex query which shows lazy loading an area where ORM all have issues but with a large cache these seem to be less in practice.

SELECT DISTINCT P.*
FROM [Products] AS P
   INNER JOIN [Order Details] AS D
      ON P.ProductID = D.ProductID
   INNER JOIN Orders AS O
      ON O.OrderID = D.OrderID
   INNER JOIN Customers AS C
      ON O.CustomerID = C.CustomerID
WHERE C.Country = @Country
ORDER BY P.ProductID

Its worth noting with services and caching LINQ2SQL can gain a significant edge as queries will be simpler.

Flexibility and Maintainability

The programming model is significantly easier for LINQ2SQL. Both have their issues with nTier systems though IMHO datasets have a significant issue with identity inserts and having to reconcile them ( much worse than LINQ where you have to re fetch/attach and re-apply the changes) .

Though both are set based systems the big gain LINQ has is the objects can have methods and additional fields via partial classes greatly improving code quality ,maintainability and flexibility.

Ease of use

Ease of use is similar for simple applications but as application get more complex LINQ2SQL gets a big edge while its clumsy to add a SUM field to a datatable adding something unusual like GMT date requires clumsy code which loops through and inserts the custom rows.

Here is an example

AdventureWorksDataContext AdventureDB = new AdventureWorksDataContext(
"Data Source=ISSY;Initial Catalog=AdventureWorks;Integrated Security=True");
//Products is the table we draged and dropped in the dbml designer
var _data = from _products in AdventureDB.Products
select _products;
dataGridViewLinq.DataSource = _data;
//Thats it!

SqlDataAdapter adapter = new SqlDataAdapter("select * from Production.Products",
"Data Source=ISSY;Initial Catalog=AdventureWorks;Integrated Security=True");
DataSet ds = new DataSet();
int x = adapter.Fill(ds);
dataGridViewADO.DataSource = ds.Tables[0];

Adding a query or altering it requires a new adapter for a Dataset for LINQ2SQL you just change the line

var _data = from _products in AdventureDB.Products
select _products;

Integration with other systems

IMHO ease of use with other packages is probably the most important thing and both systems are comparable but LINQ2SQL works better with the newer technologies.

	Datasets	LINQ2SQL
Windows Communication Foundation	Poor	Good
WPF	Excellent	Excellent
WF	Average	Good
ASP.NET	Excellent	Excellent
Forms	Excellent	Excellent
MS Report Engine	Excellent	Good
Crystal Reports	Excellent	Good

Longevity

Datasets and LINQ for SQL have similar development commitment from Microsoft ( the only one going forward seems the more bloated Entity Framework) however LINQ2SQL being based on POCO's will be compatible with most systems going forwards.

Overall

	Datasets	LINQ2SQL
Performance	Good	Good
Flexibility/Maintenance	Poor	Good
Ease of Use	Good	Excellent
Integration	Good	Good+
Longevity	Average	Good

I can see no real reason to continue using Datasets especially due to the difficult maintanence , ( its IMHO one of the main reasons RAD apps are hard to maintain) . The long term maintenance also makes the move worthwhile and all teams by now should have a sufficient skillset in working with POCO objects. If teams are working with Windows Communication Foundation they should move immediately.

Note im mainly referring to RAD style applications or services large OO type applications should consider EF(Entity Framework) , nHibernate or other auto generalting tools like LLBLGEN

Simple services and Linq for SQL - match made in heaven

Ben Kloosterman — Wed, 14 Jan 2009 12:22:29 GMT

Im a pretty big fan of Linq for SQL and it works so well with services especially smaller ones ( especially when there are no updates) .

The fact services are normally responsible for about 3 tables /conceptual domain classes mean you can quickly drag the 3 tables onto the designer and generate the code. If the structure changes you just recreate the data.

Lightweight data
Light weight service
Light weight testing
Light weight procedural code. .

These services are quick to write and easy to maintain,