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
Anonymous
September 18, 2008
PingBack from http://blog.a-foton.ru/2008/09/on-coupling-and-dependencies/Anonymous
September 19, 2008
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.Anonymous
September 19, 2008
"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.)Anonymous
September 19, 2008
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. Regards, DaveAnonymous
September 19, 2008
Don Smith is hinting at a new data access guidance package and is hoping for some feedback. Really looking forward to this!Anonymous
September 19, 2008
The comment has been removedAnonymous
September 19, 2008
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.Anonymous
September 20, 2008
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.Anonymous
September 21, 2008
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.Anonymous
September 21, 2008
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.Anonymous
September 22, 2008
The comment has been removedAnonymous
September 22, 2008
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.Anonymous
September 22, 2008
Domain model? Oh, you lucky b@stard!! Hundreds of thousands of lines of codes, but not a single proper domain object.Anonymous
September 24, 2008
The comment has been removedAnonymous
September 25, 2008
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.