http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660"All Database Systems use in fact nearly the same techniques to drive this operations fast on OS level (B-Trees, paging, caching, transaction log, delayed commits, bla bla bla)." That's true, but you missed the fact there is something different with distributed storages: - You simply can't afford yourself to run a query sequentially processing all the data there (or having even linear complexity relatively to database size). If you have such a query, you may consider it will never complete. Map-reduce won't solve the problem: the total load on system anyway stays the same with map-reduce, but since rate of such queries and the resources they need are both proportional to count of users (= data size), you get N^2 here, so it's just a question of time when they'll flood the system. - You can't efficiently run e.g. lookup joins here: each lookup will, likely, hit a different partition, so the total cost of this operation will be quite high. And so on. http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment73http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment73Tue, 17 Aug 2010 13:19:49 GMT@Thomas Maierhofer: Concerning DO.NET and support of indexing storages by it: well, that's not a complete true. The main benefit DO has here is actually a technical possibility to deal with most of storages based on indexes - simply because DO "underatands" all the underlying concepts there and properly translates the abstractions. On the other hand, this doesn't mean you can migrate your application built with DO to e.g. BigTable without necessity to change its model. Or. better to say, you can migrate it, but in 99% of cases the result you'll get won't be acceptable enough. E.g. BigTable is column-oriented distributed storage. To use it effeciently, you must represent all the data in such fashion that most of queries will touch just a small range of keys in some limited number of BigTables (or their partitions). But nearly any SQL application doesn't ensure this: even simple index lookup requires join by PK, if all required values aren't stored in index, not speaking about e.g. inheritance queries. So normally, you must implement certain changes in your model to migrate from SQL to some distributed storage, and the fact that framework supports both types of storages doesn't mean this won't be necessary. Underlying concepts are too different to hide the details by unifying APIs here. But, as far as I can judge, distributed storages is may be the only really different case. If we're speaking about relatively compact storages, nearly all of them can be represented as index storages. E.g. Azure SQL with its 50Gb limit is one of examples of such storages (think why Microsoft simply can't support unlimited database size here). Although note that targeting it, you should anyway think about such aspects as possible multi-tenancy initially. http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment72http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment72Tue, 17 Aug 2010 13:07:26 GMTSorry, just came back... Bad that blog doesn't send any comment notifications to all the commenters. @evereq: > Sure it's a little bit "art" to build repositories interfaces right, so you not end with 1000s methods in each of say 20 repositories :) But it's just your "experience" counts here, not approach itself! Probably, you didn't get the point - that's exactly what Ayende writes about. Likely, you can design your repository for N different storages, but the overall complexity of this attempt would overwhelm the profit you get from this. I.e. it's better to focus on just few similar storages (e.g. relational), rather then trying to support all of them. And about "1000s methods in each of say 20 repositories": count of such methods isn't the main problem. The main problem is that some of them won't be efficient enough on all the storages. Moreover, in real life you'll end up with the case when may be just 30% of these 1000s of methods are supported by each particular repository impl. - simply because other 60% won't be efficient enough to be used at all. In fact, you're getting the case when you're joining a set of completely different APIs into a single one by uniting the sets of methods. IMHO, this is even worse then using an intersection of these subsets :) - SRP gets completely broken. I think it should be stressed this post isn't about _possibility_ of implementing such DAL. It's about practical efficiency of implementing it. I wrote, "I have a question for guys pretending that ORM must be abstracted: can you name some widely used and relatively comlex application that really has an abstraction layer allowing to switch from one ORM to another with nearly zero code? Relatively complex means there are definitely more that 20 tables. Commercial application example would be even better." The fact there is still no acceptable answer to this question proves the idea of this post pretty well. Things become completely different, when theory meets practice. http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment71http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment71Tue, 17 Aug 2010 12:43:05 GMTDave, KV == Key/Value store. What you describe is by no means a unique situation, by the way. The problem is that you are trying to treat it as a single application. Instead, create separate services that each talk to one of those data sources. I'll have a separate post about it soon http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment70http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment70Tue, 03 Aug 2010 07:26:36 GMTAyende, Our 'DAL' solution exists of at least three projects: An infrastructure project that contains the entities (poco) and interfaces (IEmployeeRepository) and a project that implements these DAL interfaces and could use NHibernate if those entities are stored and retrieved from a relational database. The third project is not really a DAL project, it's more a DI module. We have written a DI abstraction (looks a bit like Microsoft ServiceLocator, but is also able to register those configurations in a generic way). This module says that IEmployeeRepository is handled by SqlEmployeeRepository. Actually this is how we did things before we wrote our own 'per-entity' data access framework (EntityDirector). Because of this the main application doesn't know if NHibernate (or any other ORM framework is used for that matter) is used. So the use of any NHibernate related API is prohibited in any part of the solution, except for the SQL Encapsulation implementation. Our situation is vary rare. We're not in control of where the data is located, how it's stored and in what configuration. In most cases employees need to be retrieved from a Active Directory (There's is no 'login', the Window Identity determines what a user can or can't do). Customer contacts are usually handled by the helpdesk department and each contact moment is logged in a helpdesk database. The customer (account information) itself often needs to be retrieved from an IBM DB2 database. Our application uses all these resources (data sources) to aggregate all that information and present them to the employees. So every entity can in theory have a different data source. I'm not sure what you mean with KV API. http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment69http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment69Tue, 03 Aug 2010 07:20:57 GMTDave, See my post today, you can move DAL between different storage abstraction. Not unless you have KV API http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment68http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment68Mon, 02 Aug 2010 15:57:01 GMTI definitely agree with the article. A lot of people think that repositories are a part of the DDD model for some reason. They are actually a part of the infrastructure and there is usually very little reason to make them generic. POCO simply allows class modeling without thinking too much about the data access. http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment67http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment67Mon, 02 Aug 2010 15:15:19 GMTMartin Aatmaa: Event Sourcing can turn the write side into a simple affair, but it mustn't. Especially if you have a complex BL a lot of code is affected on "simple" writes. This code must be somewhere. http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment66http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment66Mon, 02 Aug 2010 14:41:27 GMTDon't need encapsulation anymore? Well, in that case I've missed something. Last time I checked NHibernate could not access LDAP , XML or document databases.. To quote Ayende self: "There is no database, there's only persistent storage'. We write a lot of implementation solutions. And every companies uses different data sources, so we need to be very flexible in how we access these data sources. It's called a Data (notice the lack of 'base') Access Layer. In 3 or 4 years that could mean that my DAL also need to be able to access Raven-DB for example. However I agree that most solutions don't need a seperate DAL project. Most of them will never even change from database provider. However stating that encapsulating database access in a DAL is a myth is also not correct.. http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment65http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment65Mon, 02 Aug 2010 12:23:32 GMT@ Thomas Maierhofer: > CQRS is at first a optimization technique for reading data from a strongly normalized data storage. Correct. And it also simplifies (SRP) your object model by splitting the read behaviour from the write. > It doesn't help you writing data to data storage. CQRS as a pattern by itself does not. However, CQRS combined with Event Sourcing does. It, in fact, turns your write side into a ridiculously simple affair: an append only, read only, event (property bag) dump. And that's something that can be abstracted well behind a good old DAL. http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment64http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment64Mon, 02 Aug 2010 09:55:47 GMTOne word to tools like LLBLGen: If you want to use such tools you must have a completely defined schema. You must set up your referential integrity and have all your business logic defined in constraints stored procedures and triggers. I know there are nice entity relationship tools to do this and so on. In fact you do the work always twice. Once on the SQL server and once on the mapper or app server. I have done this for 15 years, and i am fed up with it. I use DataObjects.NET because it is able to generate and maintain the underlying database schema itself. It can also map to existing schema via legacy mode. Now it becomes quite cool: - I define my persistent classes and my schema will be generated. - I have my model in C# and i have less training effort for all this tools - i have my complete business logic in C# and encapsulated into the persistent class. - I have an frictionless interplay between persistent and (normal) transient objects - I only need standard version control for my CS project, i mustn't maintain any SQL scripts. - I can use all this nifty VS tools like ReSharper, AnkSVN and so on to maintain my persistent classes. - I have a well defined upgrade path which is coded in C# and under version control. And last but not least: I can use all this database tools like backup / restore, isql and so on the normal way. Finally, there is nothing wrong in coupling the business and data layer. This is the key feature of every SQL server with this referential integrity, stored procedures and triggers thing. SQL servers have got more and more features to couple the business logic and the data layer. Calculated columns, Java on the database, .NET on the database and so on. Seamless integration of BL into the data layer. But on a ORM framework you blame it? An SQL Server is the right choice in 2-tier applications or so called client-server computing. There should be no BL on the client, so it is best to put it on the server. In 3-tier appications it is best to get all the BL stuff in the middle tier, the app server. No BL on the client and no BL on the database server. Then the app server does what it intend to do, grant access for clients and enforce the business rules. I simply tell my workmate: Look at the class if you want to know what this persistent objects does. All BL is encapsulated in it. You tell your workmate: you should look on the class we generated for EF and the BL we sculpted over it. Then you should look on the mapping. And don't forget about the triggers and stored procedures, they contain a lot of business logic too. And if you change something, keep all that stuff in perfect sync. Keep in mind some update scripts will also exist and you should maintain them. Be very careful - ok it is best when you don't touch anything at all. I call this a house of cards - in my opinion it is a bug in the development process! http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment63http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment63Mon, 02 Aug 2010 09:49:44 GMTevereq: First of all an indexing engine has nothing to do with an hash table. If you look at the source code of DO4 you will find the so called RECORD SET ENGINE (RSE). This is one abstraction layer from the storage provider. There is a memory storage provider and maybe it has some hash table to store the data internally. There are also storage providers for other storage types, especially several SQL Servers. Second: Performance of Data storage. The basic performance of every data storage is determined by CRUD operations. In case of transactional storage, the commit can be added to the CRUD operations. In case of strongly normalized data and IPC (except embedded databases) it is the ability to receive the request, materialize result and send it back to the client. All Database Systems use in fact nearly the same techniques to drive this operations fast on OS level (B-Trees, paging, caching, transaction log, delayed commits, bla bla bla). Some database systems like BerkleyDB, end here, and some SqlServers use such an engine as an backend. E.G. MySQL use BerkleyDB as a backend. Every SQL Server has internally such an component which is in fact an indexing engine. I just wonder how an SQL server will scale and perform better than his underlying indexing engine? Out of the vast amount of features, there are four things that gain an performance benefit: batching, stored Procedures, triggers and aggregates like sum and avg. To put imperative code blocks (batching, SP, triggers) on the SQL server itself, you reduce the IPC roundtrips and give some context information to the query optimizer. The same is true for aggregates, which are computed on the server. In fact the DDL is mainly used to declare the business logic for the application. Todays SQL servers are overbloatet with this features. XML, geodata ... what is all put on the back of the poor SQL Server. And the server should always perform well. In the last years many projects trend to implement an app server as a middle tier and want to implement the business logic in this tier. More and more code is shifted out of stored procedures and triggers and is put in the app server itself. Buisness logic is build on top of ORM frameworks. So it is more than consequent to get all that BL stuff out of the SQL server and put it into the app server. And what keeps from the SQL server? The indexing engine! Why shouldn't a ORM threat every data storage as an indexing engine? http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment62http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment62Mon, 02 Aug 2010 07:15:48 GMTThomas Maierhofer: Ha! "DO.NET treads the underlying database as a indexing engine and not a SQL Server"... Is it really what you want to tell or I just miss something??? You want to tread full featured Oracle 11g database same way as in memory hashtable?? Reading documentation on DataObjects.NET site I found it's looks like it's not exactly the road... so? In any case, I think it's too much :) .... It what I and think many others really want to avoid :D because I think if you try to go this way you really use very small subset of features available in relational databases (even MySQL have whole a LOT of features!!!) and your performance / scalability will simply near the floor! You should work with SQL Server as with SQL Server and be able to use ALL features in your DAL that give you performance benefits when work with relational database! You should go to very limited set of features in "hashtable" + MapReduce storage engines, but use whole a lot of partitioning, distribution and parallel processing here! That is why it's really seems better approach to try build some abstraction under ORM with manual design / coding (and probably with some code generation using T4 or LLBLGen), than to just skip all features away and use only small subset :D More so as far as I understand DataObjects.NET try to COUPLE together Business Layer and Data Layer so deeply that even people who think "The false myth of encapsulating data access in the DAL" will be not happy! :) Or maybe I am wrong? ;-) http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment61http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment61Sun, 01 Aug 2010 20:11:43 GMTI will seize on Alex Yakunin's statements. To understand his position, one should keep in mind that DataObjects.NET has a very different approach to other ORM. DO.NET treads the underlying database as a indexing engine and not a SQL Server. Therefore DO.NET already acts as a full featured "Business Logic Engine" to arbitrary storage. When Bigtable or whatever can be used as a storage provider for DO.NET, there is no need for an additional abstraction layer above DO.NET. DO.NET is the abstraction layer itself. @Ralf Westphal: CQRS is at first a optimization technique for reading data from a strongly normalized data storage. It doesn't help you writing data to data storage. We have implemented such an pattern ten years ago in C++ and called it "Query Cache". Old whine in new skins. http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment60http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment60Sun, 01 Aug 2010 10:41:09 GMTTo Alex Yakunin: > 1) Examples you provided don't satisfy one of requirements with quire high probability: I mentioned there must be more then 20 tables. In short, all these examples show relatively simple system. I agree e.g. BlogEngine.NET is widely adopted. But believe me, it's quite far from real-life business application. I don't see big problem to "prolong" approach with Repositories or providers into even 200 tables in storage :) (sure maybe some changes will be needed, but generally - really don't see problem here) > 2) BigTable differs from nearly any database: ............. So what do you think, can you, taking this into account, abstract both regular and such storage? :) I take not only this into account, but much more that I know about such engines... Luck of most of features that you list make it even more "easy" to use DDD with Repositories than in case if fully relational database! I build DAL for both databases and from "client" point of view (i.e. from say business layer in our case) it's simply no difference exists what exactly resides inside repositories code! Say you build UserRepository and have here methods like Add, Remove, GetById, GetByUsername, GetAll, etc. What is the difference what resides inside repository for client (for business layer in our case)? Is it BigTable or filesystem or ATS or Oracle database??? No differences for CLIENT if you use repository via repository interface in client code! Sure some problems still apply like Lazy loading or say transactions support, but all this you CAN done :) Sure it's a little bit "art" to build repositories interfaces right, so you not end with 1000s methods in each of say 20 repositories :) But it's just your "experience" counts here, not approach itself! Btw, I just think up another example how people try to build actually complete, decoupled DAL and be able to switch ORM to some extend - look into LLBLGen - you can use here or build in ORM or switch into EF or L2S or even into NHibernate! Sure maybe you will need to add a bit of code, but this is just an approach that some can select if they need to be able to switch ORM! The only issues I see with this approach (i.e. code generation with LLBLGen) is a) it's not free, but it's not expensive if compare to developers time b) it's does not support (and maybe will never support) some "noSQL" databases.. But it's just situation right now... Maybe LLBLGen team figure out some "sophistical" ways to handle this!? If so - we will all end with LLBLGen as our "abstraction" layer UNDER ORM :) Bfn, hope this helps! :) http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment59http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment59Sat, 31 Jul 2010 19:02:58 GMTThis is the closest: [ayende.com/.../Entity-vs.-Business-Object.aspx](http://ayende.com/Blog/archive/2007/02/07/Entity-vs.-Business-Object.aspx) I really don't know where to start with CSLA, it is focused on one set of problems, and does it in a very straightforward fashion. I happen to disagree with just about all the decisions that are made there, but that is another issue http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment58http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment58Sat, 31 Jul 2010 18:16:10 GMTWell, me too, although I never seriously interested in its real life applications. I'm not saying that's what I like, it was just an example I know. But it definitely has some popularity - partially, because of books. Actually, I never heard you wrote about it. Did you? If so, I'd like to read ;) http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment57http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment57Sat, 31 Jul 2010 17:01:04 GMTAlex, Don't get me started on CSLA. I haven't seen _one_ good application using it. http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment56http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment56Sat, 31 Jul 2010 15:24:34 GMT> You end up with classes that have 3 responsabilities, act as entities from the DB, DTOS on the wire and UI bound. Fully agree. On the other hand, I know people want this. That's probably the reason behind popularity of CSLA (their entities combine last 2 features). We combine well DB+UI, + provide a special container allowing to serialize (=move) the state of such entities. In both cases the main disadvantage is big learning curve: it's far from obvious how such entities really act in complex cases. So probably, the most clean and obvious solution here is just avoidance of this (= follow SRP). http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment55http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment55Sat, 31 Jul 2010 15:23:07 GMT@Frans, @Ayende - about POCO: I also noted that original statement in its extreme form implies "don't hunt for PI/POCO, if this isn't really necessary in other layers". http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment54http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment54Sat, 31 Jul 2010 15:14:58 GMTPlanned to answer to evereq, but found Ayende and Frans already answered on nearly everything. @evereq: I'd like to commend just few parts: 1) Examples you provided don't satisfy one of requirements with quire high probability: I mentioned there must be more then 20 tables. In short, all these examples show relatively simple system. I agree e.g. BlogEngine.NET is widely adopted. But believe me, it's quite far from real-life business application. 2) BigTable differs from nearly any database: - No transactions (= different update \ access pattern). No distributed transactions (read further). - Column (family) - oriented. This affects on access patterns. - Auto-partitioned. Affects on design, etc. - Provides access to historical values. There is no analogue in regular DBMS at all for this. - There are no indexes (in fact, you have just primary index there). - It stores byte streams (~= strings); there are no other data types. - No relation consistency is guaranteed even in scope of single BigTable instance. Obviously, there are no any warranties for different BigTable instances as well. - No constraints, no triggers, etc. - Sequential scan, that is frequent access pattern in case with regular DB, is almost unusable here - because of size. Standard solution is MapReduce. So what do you think, can you, taking this into account, abstract both regular and such storage? :) P.S. Ayende, thanks about NHibernateContext - we'll use this. http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment53http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment53Sat, 31 Jul 2010 15:11:04 GMTTo Frans Bouma: > People who still try to abstract the O/R mapper away should think about why they're spending their client's money (!) on doing something completely irrelevant. It's not as if the developer abstracts away the commercial grid they're using in the UI which dictates how things work as well. Yes?? Do we speak about same things??? As for me, I will better end up attempting to abstract away ORM and spend client money on it, than some commercial GUI components (DevExpress for example) - it's usually useless to do this - you usually really change completely UI framework (say move to Silverlight or switch to jQuery Grid plug-in etc), than you just replace all DevExpress controls with Telerik or home build :D I see before in my live one WinForms project (very BIG actually) where people try to abstract away all GUI controls, they build own "labels" and "textboxes", own Grid etc :D They spend on this 90% time of project, but they just want to "bill" client more :D In reality, I think abstract GUI controls is really hard, especially for Web! (because of Javascript mostly)... You should pick up one set (say Telerik) or few sets and just use them all around :) http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment52http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment52Sat, 31 Jul 2010 10:52:00 GMT> Sure you should add a whole a LOT of code for each supported ORM! [ayende.com/.../stealing-from-your-client.aspx](http://ayende.com/Blog/archive/2008/11/21/stealing-from-your-client.aspx) That is not an acceptable solution. You basically created a port, shouldered on a huge additional maintenance problem and going to have a lot more expensive solution. > In any case they do it NICE and it's WORKS :) You can also swim the English channel, but most people take a boat or fly over. The fact that you can make something work doesn't mean you _should_ http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment51http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment51Sat, 31 Jul 2010 10:48:40 GMTTo Frank Quednau: >> just having a very shallow first look at kigg. Here, the domain and the repository is provided twice. Once for Linq2SQL and once for EF. Said ORM independence then comes at the price of multiplying a significant part of the codebase by the number of OR/Ms you want to support. As an example, introducing a new Domain Object means introducing an interface for that object, a class implementing it per ORM support and additional repository work. EXACTLY! see!? You get it in few minutes! Did I said somewhere it's not require code??? Sure you should add a whole a LOT of code for each supported ORM! :) But "common, base" code still small and nice! And you can hire few engineers each one build support of own ORM etc if needed. > Can you explain to me why I would want to pay that price if the only thing I want is to construct is a digg-style website? I understand that a company wants to show off technologies, but this leads to sometimes pretty bizarre constructions. Ha :) It's question to KIGG people :) not to me :) As I see this this guys was so experienced that decide initially to build all "infrastructure" :) Maybe they just know that someday they will want EF support, instead of L2S (i.e. was time when community was not sure about L2S future at all) etc... In any case they do it NICE and it's WORKS :) 100% agree with you! You don't need any of this complex methods for a la Digg web site or even a la Gmail! :) See my previous comments where I explain WHERE to use it will be benefit :) http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment50http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment50Sat, 31 Jul 2010 10:34:18 GMTRe Frank Quednau: > Given 2 systems A and B with each a set of features, a third system using any of A or B interchangeably will only be able to use those features that are common to A or B. Any other solution will imply knowledge about A or B or both. Sorry, not agree :) It seems like here you think not about "abstractions", but instead about "inheritance".. more so, looks like for some reason you restrict yourself to only "is-a" inheritance model and forgot about "has-a" or / and aggregation! The power of "abstraction" with repositories / providers that you use BOTH approaches (i.e. aggregation and inheritance) ! Developers tend to create very complex abstractions (sometimes too complex or just useless) and not only in DAL, but in whole a lot of layers! And it's always will be argumentation around specific situations like with DAL we have now... about say 30+ years ago, I think most of people was think that it's not possible to abstract away UI and so MVC help us now to do this! Same now happens with DAL, thanks to DDD. Your model should be simply "not aware" from persistence strategy you choice! And sorry, but ORM is just a part of all persistence we usually use in our projects! :) To Ayende: What I agree, that for some reason, .NET developers usually try to over complicate things when it's does not necessary and does not in requirements! Looking to say Grails or RoR frameworks, they does not even raise questions about switch ORM (while it's still possible there)... The issue here that Ayende have title for blog post "The false myth of encapsulating data access in the DAL" and say that it's "not work" and that's a bit not correct :) In most of web frameworks / platforms I take a look before, it's simply BY DEFAULT DAL encapsulate all data access inside :) But because such frameworks (like Django, Grails or RoR have usually just one main, default ORM nobody even try to switch it... or at least it's not common.)... in .NET world we have just too big variations and a lot of ways to build DAL: L2S, EF, NHibernate, ADO.NET, LLBLGen, ... and what is a bit issue (or maybe it's big +) that .NET framework itself does not "push" us to use any of them by default! Even latest ASP.NET MVC does not "push" us to use say EF! So that is why developers gain questions like in this blog post! :) > It is possible that you may be able to extract more commonalities between two systems than some other developer by finding adequate abstractions someone else could not think of, but then you may be just on your way to write the next great OR/M. Yep EXACTLY, and this is great and this what drive us - developers :) http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment49http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment49Sat, 31 Jul 2010 10:07:29 GMT> Did you really think that SOMETIMES it can be good idea to abstract away it? Oh, you probably want to build some abstraction on top of BigTable, if only to make it easier to do stuff. But the abstraction you'll build are going to be _different_ than the abstractions you'll have if you use a relational database. That is the key point. The whole way you access the data is completely different. > You can use in Repository code for NHibernate ALL features available in NHibernate etc! No, you can't. Because usage of those features is highlky dependant on _where_ you are using things. So either you end up with a repository with a lot of single use methods, or you use NH to define the context for operations. Beside that, I think you are missing something important when you talk about using repository to move not only between different ORM (which is hard to impossible as it is) but also between different storage formats. Different storage formats offer different access patterns. And that leads to _different code_, not just different code calling the data store, but different code in _how_ you call it. http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment48http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment48Sat, 31 Jul 2010 09:27:44 GMTAlex, You writer your own context based on your entities. Like you do with EF Code Only, frex. http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment47http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment47Sat, 31 Jul 2010 09:21:49 GMT> DAL is a good pattern wich allow me to share classes in servers, middle and client sides (obviously click once is a must for this). You _never_ want to do that. You end up with classes that have 3 responsabilities, act as entities from the DB, DTOS on the wire and UI bound. That lead to very nasty code and is a huge violation of SRP. http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment46http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment46Sat, 31 Jul 2010 09:20:16 GMTO/R mapper frameworks are not a solid abstraction, the abstraction is leaky because the services the O/R mapper provides are embedded into the application, no matter what you do. I therefore agree with the article. People who still try to abstract the O/R mapper away should think about why they're spending their client's money (!) on doing something completely irrelevant. It's not as if the developer abstracts away the commercial grid they're using in the UI which dictates how things work as well. Here's another one, in the same line of thought: if an o/r mapper is bleeding into the app anyway (as you use the services, so you don't have to write that yourself, you GAIN by this 'bleeding'!), is POCO really that important? After all, if the O/R mapper can't be swapped easily, if at all, why bother how the persistence classes are created, if the o/r mapper provides the services you want/need? POCO makes swapping easier, but it's still almost undoable, so it's a non-feature. http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment45http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment45Sat, 31 Jul 2010 09:10:28 GMT>> In reality, this is nothing more that a simplification of abstractions to minimal common subset of features. > Why to minimal??? Still not get you!! Given 2 systems A and B with each a set of features, a third system using any of A or B interchangeably will only be able to use those features that are common to A or B. Any other solution will imply knowledge about A or B or both. It is possible that you may be able to extract more commonalities between two systems than some other developer by finding adequate abstractions someone else could not think of, but then you may be just on your way to write the next great OR/M. http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment44http://ayende.com/4567/the-false-myth-of-encapsulating-data-access-in-the-dal#comment44Sat, 31 Jul 2010 09:00:22 GMT