Software architecture is about making hard choices.
It is all about trade-offs between performance and security, scalability, maintainability, etc.
The more reuse you have, the more coupling you have. At some point (very rapidly) the cost of coupling outweighs the benefit of reuse and you lose.
The more security you have, the more overhead and complexity you have. At some point (very rapidly) the cost of security becomes quite high - and may or may not be worth it, depending on your actual threat analysis.
The more abstractions you employ (for things like data access), the lower your performance, and often the higher your complexity. It seems counter-intuitive that abstraction would increase complexity, but look at dependency injection and inversion of control and the complexity they cause - all because of increased abstraction...
In Chapter 18 I discuss a wide range of options for implementing data access in CSLA .NET. I discuss many of the same options, and provide code samples, in the N-Tier Data Access video.
CSLA .NET allows you to use the highly efficient, but not overly abstract, raw ADO.NET technology. You can use it directly in your objects (simplest), or in a separate DAL using the System.Data interfaces (more complex, but better layering).
Everything other than raw ADO.NET will cost you in performance, because everything else (LINQ to SQL, EF, TableAdapter/DataTable, NHibernate, LLBLgen, etc) is an abstraction layer on top of raw ADO.NET. So by definition they will all cost you performance - but people use them in the hopes that they provide more productivity and thus are worth it.
And they probably are worth it. Hardware is much cheaper than development/maintenance costs. If you save just a few hours of development time, you can buy another server. A bigger server.
What I'm suggesting, is that architecture is about making hard choices - and they are not all technical. They are overall business choices. A good software architect will do cost/benefit analysis that includes development, maintanence, hardware, infrastructure, testing, usability and other factors relevant to the project.
Sure, using EF is slower than raw ADO.NET. But if I can spend $10k to buy a bigger server (to offset the lost performance) and the productivity offered by EF saves me $20k in software development costs, this seems like a win.
Whether EF actually saves you that much time, I'm not sure - that's something you need to decide. Using code-gen tools, raw ADO.NET is terribly productive...
Personally I default to use raw ADO.NET, because I really don't find it to be that hard to use, and it provides the best performance. But if my business requirements include database independance (SQL/Oracle for example) then I'd give serious consideration to using some higher level of abstraction (because I don't want to deal with the mismatches in terms of data type conversions, database exception types, etc).
Copyright (c) Marimer LLC