ORM

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);

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 .

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)