Both of these technologies are very powerful ways of implementing object to relational mapping.  With LINQ to SQL, I feel it should be built on top of “views” so when one makes table changes the whole system doesn’t come crashing down.  The Entity Framework seems to cover such scenarios in its mapping functionality.

            However, neither seems to place nice in the n-tier model.  That is, in which DLL should the EDMX or the DBML files belong?  In one sense they do data access and in another they define business entities.  On the one hand, I suppose one could put them in the data access layer and use business logic to convert those entities to ones defined in the business tier.  Yet, that seems like a lot of work and bit un-refactored.  On the other hand, we could put them in the business layer, but then we are doing data access from the business layer.

            I would like to see a system where the data access is decoupled from the entities.  For now, I am going to add these files to the data access layer.  Furthermore, I am going to add the Data Contracts from my service layer to my business layer: not really happy about that.  However, this will allow me the ability to use my business layer as a translator to expose my entities to the Silverlight frontend.

            I could add the data access to my service implementation project, but I think it is better to do such translations in the business layer.  Obviously, we could build duplicate entities in the business layer and translate twice, then again to much work and not that refactored.