Attention: We are retiring the ASP.NET Community Blogs. Learn more >

4 Comments

  • Just my words.



    Ridiculous.

  • I have not had a chance to look at Yukon in detail so some of my comments might miss the mark. Having said that, I want to say that IT DOES NOT REALLY MATTER where the business logic reuns physically. For me the purpose of the different tiers is to isolate the different functionalities from each other so that they can flex independently of each other. I want to be able to change things in one tier without having to necessarily change things in other tiers.



    Obviously, I can achieve that by creating separate physical assemblies and running those assemblies on different boxes. (However, I have seen separate physical assemblies that were so intertwined with each other that it was impossible to change one without changing all of the others.) I can also achieve that by running the assemblies on the same box. And I can acchieve that by building them all into one assembly and exercising some discipline to keep them from getting intermixed. My point is that it is about discipline, not packaging.



    I am assuming that Yukon will let me create separate classes to handle the business logic, perhaps even separate library assemblies. If database access performance is a big driver in my architecture (as opposed to maintainability or scalabilty or security or availability or ...) then placing the business logic on the SQL box inside of the process boundary is a "good thing". I, for one, am glad to have the option to do that; just as I am glad to have the option to "stand off" and put the business logic on a different box.



  • Jon, all good points and I could not agree more. When I think tiers, I think logic and ideally all running in the same process if possible. Just seems foreign to me to start thinking about about this on sql server. As you point out, it is yet another option.

  • Jon: as far as I understand it, when you program against the in-process ado.net driver, you can't move that code to another machine, it has to run inside Yukon. This might not be a problem though, since this is a matter of the DAL anyway, but nevertheless it should be noted.



    I don't think it will change the landscape a lot, this internal CLR. Java didn't kill PL/SQL either, on the contrary, neither did Java kill sql on DB2.



    What is nice is the data retrieval methods which can be fast now. However when you then don't do a lot with the data inside Yukon, it doesn't make a lot of difference: the data gets exported to another process then anyway. So to take advantage of the fast inprocess ado.net driver, you have to run the BL code consuming some of htat data inside yukon also, otherwise it doesn't make sense.

Comments have been disabled for this content.