On coupling and dependencies

a-foton » On coupling and dependencies

a-foton » On coupling and dependencies — Fri, 19 Sep 2008 12:32:26 GMT

PingBack from http://blog.a-foton.ru/2008/09/on-coupling-and-dependencies/

re: On coupling and dependencies

Corey — Fri, 19 Sep 2008 16:15:11 GMT

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.

re: On coupling and dependencies

Gareth Rowlands — Fri, 19 Sep 2008 16:15:19 GMT

"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.)

re: On coupling and dependencies

David Hayden — Fri, 19 Sep 2008 20:19:05 GMT

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,

Dave

New Guidance Package on Microsoft Data Access Technologies

PnPGuidance — Fri, 19 Sep 2008 20:56:53 GMT

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

re: On coupling and dependencies

David Nelson — Fri, 19 Sep 2008 21:11:17 GMT

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.

re: On coupling and dependencies

Don Smith — Fri, 19 Sep 2008 22:41:24 GMT

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.

re: On coupling and dependencies

Ray — Sat, 20 Sep 2008 19:48:28 GMT

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.

re: On coupling and dependencies

Adam — Mon, 22 Sep 2008 08:38:21 GMT

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.

re: On coupling and dependencies

Bogdan Nedelcu — Mon, 22 Sep 2008 12:22:17 GMT

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.

re: On coupling and dependencies

Torbjørn — Mon, 22 Sep 2008 15:00:59 GMT

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

http://contikistrip.kjempekjekt.com/?p=6

re: On coupling and dependencies

David Nelson — Mon, 22 Sep 2008 23:09:08 GMT

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.

re: On coupling and dependencies

Torbjørn — Tue, 23 Sep 2008 07:51:29 GMT

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

Business sense on coupling and dependencies

Walter — Wed, 24 Sep 2008 21:16:03 GMT

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.

re: On coupling and dependencies

Don — Thu, 25 Sep 2008 23:47:16 GMT

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.