On coupling and dependencies

For my whole software development career I’ve been focused on the enterprise app dev space. (I did try to join the Zune team at one point, but that’s the topic of another post 😉 While some people baulk at the term “enterprise” it does actually carry certain connotations to many of us. This blog entry is an inquiry - a checkpoint if you will - into that space to see if things have changed recently.

One of the things that has been consistent in almost all of the enterprise implementations I’ve written and seen customer write is the assurance that custom code be very separated from vendor technology. When you have millions of dollars invested in a [multi-year] solution, the last thing you want is for a vendor that you’ve taken a dependency on (yes, Microsoft is a vendor in this context) to change something that causes an unexpected investment in revisions.

Don, where are you going with this?

Well, I’m in the process of starting a guidance project that deals with data access – specifically, using the latest Microsoft data access technologies. Since the patterns & practices team focuses primary on enterprise scenarios, to me, this means “how to build the most appropriate data access layer (DAL) for your scenario.” (as always, please correct me if I should think about this differently)

In preparation for this guidance project, I’m going through and trying to get smart about things like LINQ to SQL, the ADO.NET Entity Framework, and what it means to use them to build a DAL. In the process, it looks like the creators of these technologies expect the developers (you) to NOT isolate their code from vendor code (LINQ to SQL is integrated into the actual C# and VB.NET languages and EF expects you to use the entity classes directly from your business logic).

So my question is … are you okay with this? In using LINQ to SQL and/or EF, are you okay with the dependencies you have to take in your DAL or are you jumping through hoops trying to avoid it?

Of course I’m mostly asking to try to assess what you would expect from the guidance. Thanks for your help.

Comments (15)

  1. Corey says:

    Hmm, sounds like you’re asking a question you already know the answer to… Please provide a way to stay decoupled from any particular technology.

  2. Gareth Rowlands says:

    "In using LINQ to SQL and/or EF, are you okay with the dependencies you have to take in your DAL?" No, of course I’m not OK with that. Nobody worth their salt is.

    It’s not just about dependencies on vendor code, it’s about dependencies in general. It’s not necessarily bad having a dependency, it’s bad not managing it. For example, I’m probably OK with a dependency on SQL Server, since I’m not likely to swap to another database and that level of abstraction would cost. But I’m not OK with spreading TSQL thoughout my application.

    Fundamentally, it’s about separation of concerns. The reason I don’t want my domain model depending on the data access mechanism is because *it’s a domain model* – it’s about whatever the problem domain is about, not about data access. In contrast, I probably don’t mind my DAL depending on the database access mechanism because the whole point of the DAL is to access the database.

    But I think you know all this. So my advice is to you is "do the right thing". (And don’t worry about aligning your advice with the marketing messages from product/technology groups – it’ll work out best in the long term.)

  3. David Hayden says:

    For Enterprise Applications I am jumping through hoops avoiding the coupling. Preferring LINQ to SQL with its better POCO Model, I ended up writing my own Unit of Work and Repositories that wrap LINQ to SQL to achieve looser coupling and easier testability.

    If you are considering a new guidance package to help enterprise developers in this endeavor using Microsoft Data Access Technologies, I can tell you that it is badly needed.



  4. PnPGuidance says:

    Don Smith is hinting at a new data access guidance package and is hoping for some feedback. Really looking forward to this!

  5. David Nelson says:

    LINQ has such great promise: create a strongly typed "query" based on your domain model, and then use that query to get data from your relational database (or whereever). The problem is that the way this is currently designed, you cannot define an abstract query and then pass it to your data layer to execute; you have to start with your data layer (the "Data Context" that the LINQ to SQL designer generates) and build the query on top of it. This completely violates separation of concerns.

    It is so disappointing that LINQ to SQL comes so close to hitting the mark and then falls short.

  6. Don Smith says:

    Corey, I just wanted to make sure things hadn’t changed 🙂 thanks.

    Gareth, yes, I definitely agree with your points on dependency management and separation of concerns. You have my word I won’t pander to the marketing hype, and will stick to using the right technologies in the right way for specific scenarios.

    David, I’m not yet sure if the guidance will be automated or not. The deliverable will certainly have source code and written guidance, but no promises on DSLs or code generation – not really sure we need it in light of what is already provided. But if you have ideas, you know what to do 😉

    David, yea, I’ve been playing with LINQ to SQL too and have really fallen in love with the LINQ technologies overall. The strong typing is killer, but I’m skeptical of queries based on the *domain* model. I’m more comfortable with queries based on the *data* model. I haven’t worked out the separation yet, but I’m hopeful we’ll all get it figured it.

  7. Ray says:

    Do we really need more data access guidance? That whole area seems pretty saturated but what’s really missing is a strong N-tier story from MS using their own stack (Linq to Sql/EF) instead of the 2-tier data + ui model we’ve been presented so often.

    I was kind of hoping that EF would have built on the shoulders of Linq to Sql and provided this, but it clearly went a parallel path, it’s just a higher-abstracted version of the same thing L2S provides.

  8. Adam says:

    I am becoming tired the short-sightedness of some framework designers.  

    It is simply not acceptable in an enterprise environment for the EF to expect you to use the EF dependent entity classes directly in business logic or even the ui model.

    They could have saved a lot of effort for thousands of people if they designed the EF with POCO’s… but no, we then have to stuff around wasting time and making these ourselves.

  9. I speak as one who developed a in-house data access and business layer above the .net platform for about 5 years, used in enterprise applications. We changed from COM+ to .NET having in mind the 3-tier architecture and updated the model to fit all the new MS technologies available.

    I believe LINQ is the future but many risks are involved when trying to change the DAL implementation in an existing application. We decided to use DSL’s which model the DAL access and thus to be somehow independent of the implementation.

    So my opinion regarding your questions, is: do it and we will follow in our own way. Ours is through DSL for generic things and probably LINQ or others for specific actions.

  10. Torbjørn says:

    I would like to comment with a short comic strip inspired by the place I work. I think it says it all:


  11. David Nelson says:

    How do your front or middle tiers create queries based on the data model, when they have no idea what the data model looks like? The only thing they see is the domain model, which is how it should be.

  12. Torbjørn says:

    Domain model? Oh, you lucky b@stard!! Hundreds of thousands of lines of codes, but not a single proper domain object.

  13. Walter says:

    Hi Dan…First I think the new guideline is definitely a life saver for us.– EF, Data service, LINQ-to-this-and-that puzzle lot of developers who used to think DataAccess block is the only solution.

    My view on the dependency is that it has to bring in economical benefit. Bottom line, we all build software on something, adding LINQ probably would not be different from other dependency. I would like to see your guideline to have some cost metric analysis there, e.g. how much time can be saved using LINQ. It will be the dominant factor for us to pick the solution.

  14. Don says:

    Ray, I don’t look at this guidance project as a way to show how to use these new data access technologies as much as how to build data access layers with them. In doing so, the code we use to illustrate this will be an n-tier app. Hopefully we’ll be able to provide some clarity around the LINQ to SQL/Entity Framework discussion.

    Adam, I totally hear what you’re saying and agree. The good news is there will be POCO support in the next version of EF – I’ve already seen it demo’d and it looks pretty good. I would like for this guidance to help devs/architects use all versions of EF as well as other technologies.

    Bogdan, using DSLs and code generation is a good way to add more consistency, productivity, and predictability to your solutions – and DALs especially tend to benefit nicely from this approach. I’d be interested to learn more about the DSL you’re using (have built?). Are you using them to implement the Repository and/or Factory pattern?

    Torbjørn, thanks for the comic … very funny.

    David, I think I originally missunderstood. I agree that using LINQ against the domain model is very nice, but I was thinking you said using LINQ to SQL against the domain model, which doesn’t really make sense now that I think about it.

    Walter, thanks for your comment. I really like the idea of the guidance providing cost metrics (cost/time, complexity, evolvability, etc) on the various approaches. I have an idea for an approach to take with this guidance that I’ll describe in a forthcoming blog post.

    Thanks again.

Skip to main content