http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660The answer for me would me a mostly straightforward "yes." You make way too many assumptions about what "application" means -- granted, a large percentage of .NET applications are web- or CRUD-oriented, in which case tools such as the ones you advocate are invaluable. However, there are a lot of application types that do not necessitate such tools (some examples: compilers, business engines, 3D engines, non-database server side software...), even though it sometimes helps. http://ayende.com/2403/you-have-only-the-clr-2-0-now-go-and-build-a-complex-application#comment13http://ayende.com/2403/you-have-only-the-clr-2-0-now-go-and-build-a-complex-application#comment13Mon, 28 May 2007 08:50:41 GMTAhh I read my post and realised I could've written it better - I do use interception all the time - what I meant before should be taken in context of DSLs vs. frameworks in terms of performance. Chris http://ayende.com/2403/you-have-only-the-clr-2-0-now-go-and-build-a-complex-application#comment12http://ayende.com/2403/you-have-only-the-clr-2-0-now-go-and-build-a-complex-application#comment12Sun, 20 May 2007 00:59:58 GMTMike, As fast as implementing it directly? Sure, you get to write the code only once :-) Seriously, it is probably costing another method call, but that it literally nothing in the grand scheme of things. As always, measure and find out, but I'll willing to bet that there isn't a reasonable scenario where the interception would be the biggest issue. http://ayende.com/2403/you-have-only-the-clr-2-0-now-go-and-build-a-complex-application#comment11http://ayende.com/2403/you-have-only-the-clr-2-0-now-go-and-build-a-complex-application#comment11Sat, 19 May 2007 19:19:21 GMTAyende, Thanks for the comments. I reread that post and I get what your doing, yes it's very cool. Can you say that interception in this manner is more performant than simply implementing INotifyPropertyChanged? The best argument I can see for your approach is that dotnet databinding is so screwed up between asp.net winforms and wpf so you may have a good point there. Now I am going to go read your latest p&p post, it's saturday and should be quite spicey :) http://ayende.com/2403/you-have-only-the-clr-2-0-now-go-and-build-a-complex-application#comment10http://ayende.com/2403/you-have-only-the-clr-2-0-now-go-and-build-a-complex-application#comment10Sat, 19 May 2007 19:16:02 GMT>Why not build in the basic plumbing and in the rare case you neeed more go grab the tool? Because it is more maintainable to put it in the tool in the first place. I dislike the idea of having to put duplicate code in my entities. I would rather build a framework that understood the way I worked than use the other approach. Check my post about adding INotifyPropertyChanged to Nhibernate. http://ayende.com/2403/you-have-only-the-clr-2-0-now-go-and-build-a-complex-application#comment9http://ayende.com/2403/you-have-only-the-clr-2-0-now-go-and-build-a-complex-application#comment9Sat, 19 May 2007 15:03:13 GMT@Chris, Object proxies are _extremely_ useful, they stand in the foundation of NHibernate, AoP, and a lot of other interesting ideas. From my understanding, Andres is objecting to the idea. http://ayende.com/2403/you-have-only-the-clr-2-0-now-go-and-build-a-complex-application#comment8http://ayende.com/2403/you-have-only-the-clr-2-0-now-go-and-build-a-complex-application#comment8Sat, 19 May 2007 14:49:22 GMTMike, My issue is that having a DSL generate the code still doesn't mean that you can ignore code duplication. I don't think that aspiring toward zero tools dependecies is even a good goal. It basically means that you have to do everything from scratch. About object proxies, that really depends on how they work internall. To take Castle.DynamicProxy2, for instance, that one is highly optimized, I don't think you would be able to get better performance if you were writing it by hand. http://ayende.com/2403/you-have-only-the-clr-2-0-now-go-and-build-a-complex-application#comment7http://ayende.com/2403/you-have-only-the-clr-2-0-now-go-and-build-a-complex-application#comment7Sat, 19 May 2007 14:41:21 GMTChris, Just because there are only a few DSL's available today and yes I agree most generate ugly code, thats not to say that the concept isin't a solid one. I have high hopes for activewriter, the best example of a DSL today in my opinion. DSL is young, and I see huge potential here. I am not saying never use a 3rd party or OSS library, just that good DSL Designers can eliminate some of this. Gil, I agree balance is needed here, I try not to run to a tool unless absolutely necessary. --- One thing I dont really get, and this is slightly OT. When do you ever design an entity that does not require ( persistence, validation, rules, authorization, binding ) so why not build at least some of this this into the library? I am not talking about hardcoding rules or validation, simply adding the events and interfaces and services necessary to facilitate this, rather than doing POCO and tools. Why not build in the basic plumbing and in the rare case you neeed more go grab the tool? http://ayende.com/2403/you-have-only-the-clr-2-0-now-go-and-build-a-complex-application#comment6http://ayende.com/2403/you-have-only-the-clr-2-0-now-go-and-build-a-complex-application#comment6Sat, 19 May 2007 13:22:13 GMTI agree with most of the above. Although my personal development lately are very small projects, I can't live without TestDriven.Net or Reflector. I haven't used IoC, but I expect this is something I'm going to use from now on. As opposed to to small group that can do whatever they want and keep the cost at a minimum, in bigger team there's a bigger marginal cost of all the tools out there. If everyone uses his favorite tool, other people need to also know it to support it. There should be some kind of a balance there for the optimal point. http://ayende.com/2403/you-have-only-the-clr-2-0-now-go-and-build-a-complex-application#comment5http://ayende.com/2403/you-have-only-the-clr-2-0-now-go-and-build-a-complex-application#comment5Sat, 19 May 2007 07:17:39 GMTYes I agree with Ayende here - if you're going to use a DSL, use only the DSL. DSLs typically generate code that is ugly. BTW, I thought DSLs were used to model business logic (and possibly UI) & generate code from it? I do think codegen tools for domain models are useful. If object proxies are useful enough, I'm sure MS will implement it into C# 4.0 and optimize the compiler for it. I think readability & maintainability are much more important considerations than performance in enterprise apps - if you're going to need performance, then have some sort of intermediate parser between your code and the compiler to optimize it (except I'm not sure whether such a beast exists yet). Chris http://ayende.com/2403/you-have-only-the-clr-2-0-now-go-and-build-a-complex-application#comment4http://ayende.com/2403/you-have-only-the-clr-2-0-now-go-and-build-a-complex-application#comment4Sat, 19 May 2007 02:40:29 GMTI completely respect and understand your point of view, you should get the MVP just for speaking your mind on this blog and the debates that arise :) Software Factories, for which I am not to exited about ( they are downright scary ), are for generating entire applications. DSL Tools on the other hand are for generating sections of a domain. My only concern about DSL is moving forward to VS.NEXT the DSL no longer works and you have a problem even making a small change. So if a DSL is generating a DAL with zero tool dependancy, is this really a problem. I know tools like NHibernate perform well, and hats off to the work there, but is this really a problem. Take object proxies for example, and I have profiled them, they have performance impacts. My thinking is to have a little bloat / smell slightly larger memory footprint, provide the funtionality you need all generated by a DSL. Now this starts leaking into another discussion about the basics needs of a domain object ( persistance, binding, validation, rules, authorization ) so we need 5 tools / frameworks? Why not build this in using the framework? I know this is a different approach and I totally respect your opinion on this. Thanks for the great blog. http://ayende.com/2403/you-have-only-the-clr-2-0-now-go-and-build-a-complex-application#comment3http://ayende.com/2403/you-have-only-the-clr-2-0-now-go-and-build-a-complex-application#comment3Fri, 18 May 2007 21:20:22 GMTMike, I completely disagree, the DSL tools are good in concept, but the implementation is that it is trying to basically code-gen entire applications. That is code duplication, I will push everything to a common framework and then I get the same benefit that I would from a software factory, but I wouldn't have to deal with nasty code duplication issues _and_ I would have a better design. About perf, I would like to see numbers first, you would be surprised how much work goes into making the "general" tool really performant. http://ayende.com/2403/you-have-only-the-clr-2-0-now-go-and-build-a-complex-application#comment2http://ayende.com/2403/you-have-only-the-clr-2-0-now-go-and-build-a-complex-application#comment2Fri, 18 May 2007 15:15:13 GMTI think this is one area DSL Tools will make there mark as they can codegen from just the .NET Framework rather than using another library. OR/M may be a little to complex for that at the moment. I always try to use as few external libraries as possible even if it means using custom generation, as you get more specific performant code. http://ayende.com/2403/you-have-only-the-clr-2-0-now-go-and-build-a-complex-application#comment1http://ayende.com/2403/you-have-only-the-clr-2-0-now-go-and-build-a-complex-application#comment1Fri, 18 May 2007 13:26:42 GMT