Coffeehouse Thread

30 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

.NET Framework Future ?!

Back to Forum: Coffeehouse
  • User profile image
    JParrish

    I mentioned Eclipse because it is deffinately not swing based. SWT was created to provide a rich set of native widget interfaces that still allowed for it to be done in a platform agnostic manner. I have never run a Java desktop application in windows that ran as well and looked as nice as Eclipse.

    You can see it in action here:
    http://download2.eclipse.org/downloads/drops/S-3.0M8-200403261517/eclipse-news-part1-M8.html


    And a backgrounder on SWT design goals here:
    http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html

  • User profile image
    jcarlisle

    You can do "generic" data access components using ODBC or OLEDB but the point that the SQL client is optimized for data access against SQL server and if your're in an environment where you know your going to hit against SQL server why wouldn't you want the optimized/faster route. IMO a better approach to having the flexibility if you need it (albeit more work) is to have seperate data access components and use the one that's optimized for your particular data source. In the end its all about compromise but when would you rather have a good fitting comfortable shoe that you can win races in or a shoe that everyone can wear but is comfortable for noone.

    IMO coming from both a C++ and VB (mostly VB) background .NET IS revolutionary for me. I can do many things that we're a royal pain in the a$$ or downright impossible in VB. I'm much more productive then I am in c++ for things like writing windows services and even more productive then the VB4,5,6 days for many of my tasks. Just because it has ties to the "old" COM system doesn't mean that .NET isn't  revolutionary its just maybe that aspect of .NET isn't as revolutionary but thats a very small element IMO. There have been very few times when I've had to think about COM being behind the scenes (both of which were the places you've already noted - the webmail namespace and enterprise services) and even fewer times when the use of COM behind the scenes has hindered my in any way. I do think it's important and some times fun to see what's going on behind the scenes and yes I do poke around quite a bit but no I don't go reading the rotor source code but then again .NET wouldn't be too productive if I needed to do that to get my job done using .NET (alhtough in some areas it can be very beneficial and these are the areas I usally look deeper into when I need to) but I do truly envy people who have the time to get that low level at a global scale to see what's going on under the hood cause I do wish I could Smiley

    And for certain aspects of COM still being used behind the scenes I go back to saying... what does it hurt? Do you feel "cheated" because you found out that it's not completely "new" and that it uses some COM still so its all been a big lie? I still go back to my original comment that .NET is much more then just COM in new suit. The .NET framework .NET gives me the increased productivity, power, and options that I didn't have all in one area before and IMO it has been revolutionary for me. Obviously others will have different experiences and those are completely valid too..

    Josh

  • User profile image
    billy

    JParrish, After furthure investigation (here at home on my Mac) I don't have that much GUI stuff in Java. The ones that I do aren't as responsive as IntelliJ. Take JBidWatcher for instance, it is not bad, but it doesn't take that many items in the list view to bog it down a bit. I'll have to look at work on Monday, but perhaps, IntelliJ is an exception, and doesn't represent the rule.

  • User profile image
    billy

    jcarlisle, I'm not saying that COM in the background is bad from a performance (unless it was a problem with the COM implementation) or productivity standpoint. Just that there are some things that really keep me up all night digging around the framework, and are exciting, while other aspects that are just wrapping old COM functionality do the opposite. It's more as you say, that I feel I have been *sniff, sniff* misled. Where it really comes in to play is when we are deciding whether something should implement something in .Net or J2EE. Naturally the Windows folk say .Net while the Java guys say J2EE. And really the deciding factor is always performance, and stability followed manageability. This is when we (the .Net folk) start quoting things we get from MS about those topics. Let me tell you, it's hasn't been good when we win an argument with "but it's different now" or "it works better or easier now" then have to come back and say "well, underneath, it's still the same old thing. It's just that the semantics are different on the surface, becuase performance and stability do not come from easyier development or better productivity during the coding cycle. It's what's under the hood that matters.

  • User profile image
    prog_dotnet

    1.
    The .net arcitechture as such are not slower than native c or c++ code, but the current implementation is..
    Your code dont execute directly on the hardware. Its managed by a "man in the middle", the jit compiler during runtime. And thats why you have the 10 % or so, performance hit.
    Microsoft actually has some of the componets in the gac precompiled to native code suited for your
    underlaying hardware..You can argue that precomileing makes a less versetile system, cuz if your precompiled component relies on 3 other components, and one of those breakes  your precomiled component are made useless.(windows update)
    But as I see it, this is the direction of the .net execution model for the future.

    2.Second. The .net runtime knows more about the underlaying hardware than usual c and c++ compilers, and can in theory produce faster code than a c/c++ compilers today.
    That is years off, but the arcitechture supports it.

    3.
    Modern software executes based on a runtime enviroment;
    your app->run time enviroment-->os-->hardware

    Why?  Its portable and secure. If you have the runtime on your plattform, the app wil run. The runtime enviroment also provide a sand box enviroment for code execution
     Jave executes this in a similar way :
    ----------------------------------------

    java app-->jvm-->windows-->x86

    . Java app-->jvm-->mac os-->ppc.

    java app-->jvm-->palm os-->arm

    ----------------------------------------

    In windows you have;

    app written in any .net language based on bcl and your own classes

    runtime

    os

    hardware

    like:;

    -------------------------------------------------
    app -->clr-->windows-->x86

    app -->clr-->pocket pc-->arm

    app-->clr-->freeBSD(mac)-->ppc

    app-->clr-->linux-->x86

    ------------------------------------------

    So .Net is portable. As long as you have the man in the middle (runtime), the code will execute. Mono is about 70 % finished, but can only run web apps as the win forms classes are not implemented yet..but they will be in future versions.

  • User profile image
    Lwatson

    unix? wrote:
    I´ve developed a universal Data Access component. Because I think it is bad to use the SqlClient, OracleClient, ... If you change the DBMS system you have to change the whole program code. 


    Interesting... How does your universal data access client leverage features of one DBMS vs the Other for example SELECT @@IDENTITY, or some of the SQLSERVER Stored procedure quirks vs different but just as effective quirks of ORACLE or DB2 or POSTGRES or MYSQL?

    Or does your universal access use the smallest common set of functionality.

    SELECT INSERT UPDATE DROP DELETE CREATE ALTER and thats about it. Hell you would even have to forgo using the TOP N or LIMIT N syntactic features, or you wind up doing direct table access on datatables in memory?


  • User profile image
    unix?

    Lwatson wrote:
    unix? wrote: I´ve developed a universal Data Access component. Because I think it is bad to use the SqlClient, OracleClient, ... If you change the DBMS system you have to change the whole program code. 


    Interesting... How does your universal data access client leverage features of one DBMS vs the Other for example SELECT @@IDENTITY, or some of the SQLSERVER Stored procedure quirks vs different but just as effective quirks of ORACLE or DB2 or POSTGRES or MYSQL?

    Or does your universal access use the smallest common set of functionality.

    SELECT INSERT UPDATE DROP DELETE CREATE ALTER and thats about it. Hell you would even have to forgo using the TOP N or LIMIT N syntactic features, or you wind up doing direct table access on datatables in memory?




    Hello, the component uses the fact that each SqlDataReader, OracleDataReader, ... implements the same interfaces provided by ADO .NET. For example the following interfaces can be used: IDbConnection, IDbDataReader, ...
    I´ve developed my own generic DataAdapter, ... with the interfaces provided. If you don´t want to wite much code you can use a helper class that "returns interfaces" instead of special classes. You can use the interfaces to work with.

    public IDbConnection GetConnection(string provider)
    {
    ...
    }

    The @@identity, and all these strings have to be in a configuration file. You can change the DBMS and you don´t need to change the code - you doesn´t have to recompile. You have to change the DBMS commands (Select, ...) too if your target DBMS does not have the same functionaliy like the source.

    In the 2.0 Framework M$ doesn´t use these interfaces. They use base classes from which they derive. They support a feature like my "generic" data component. You give the class method the DBMS type and you get a derived class from the base class. You use the base class in your code. That´s the way polymorphic is working in OOP. And you doesn´t have to use a specialized SqlCommand or OracleClient type in code. 

     

  • User profile image
    Lwatson

    Unix...

    I understand all of that about the interfaces being exposed through the classes.
    I also understand that by creating the interfaces in your own classes you can have a single class that can do all the things that the custom classes can do.
    There is one issue that I dont understand. If you have some specific things that work in one database server and not in others. The generic class that exposes the interfaces could be made to take advantage of those specifics, but an application built with that generic access mechanism that is being messaged to take advantage of a database server specific function or feature will not be able to automatically start using a different database server that does not support that specific function or feature. So if you have to alter that application is some way for use with a differing database server then why NOT take advantage of any performance benefits of using database specific access mechanisims within the .NET context. You still have to do something to the app to get it to work on a different database server anyways. unless you use the bare minimum features necessary to support simple sql on a datastore.

  • User profile image
    unix?

    Ok.

    I use the specific database access components through the interfaces -> I don´t think that this data access method is much slower than using the original SqlConnection, ...

    You have the stored procedures, ... in a configuration file to be flexible. You can easily change these DBMS specific things.

    But why recompiling the application ? I don´t want to recompile the application if I want to move the app to another DBMS. I do not want to search and replace SqlConnection with MySqlConnection, ...

    There are no database specific things in the 1.1 Framework to for example the Sql Server. All ADO .NET providers use the same interfaces provided by Microsoft. The only specific things are the connection string, command strings, ... all these things are stored in an xml configuration file.
    In System.Data there are all database types stored in DbType -> these types are generic types for all ADO .NET providers (parameters, ...)

  • User profile image
    Lwatson

    To be honest I have found the tools for manipulation of Code in source form to be far easier to manage than the tools designed to manipulate giant XML configuration files.
    Another aspect is that these configration files being world readable open yourself up all sorts of nasty possibilities if the user base gets on to know that 'I can tweak this piece of text to make it do this...'.
    Of course you could make all that part of a binary resource but then you have to go through the compile and re-compile cycles anyways.
    So whats the diff?

  • User profile image
    unix?

    I use these xml configuration files for server applications for now -> and the server has to be secure Smiley.

    But you can use them on client applications too -> they get the latest version from server - encrypted. The client saves a hash of the file and can check if there is a new one on the server. If there is one, the client downloads the file from server.

    So you have a very flexible client application which can be managed from a central server with configuration files. And you don´t need to recompile the application.

    But remember:
    If you don´t use an obfuscator program your managed applications can also be read by everyone -> they can use an application like "Reflector" to get the things out of the compiled program/resources. And they get all commands, the connection string, ...

  • User profile image
    Lwatson

    As for the obfuscator issues. I am aware of the fairly easy to read nature of the IL code. Here at TAI software our client have code access anyways because they are given the source for their own versions of our applications.

    We wrote the stuff in .NET and if they wanted to give us the gas and support their own applications inhouse so be it. We typically have something of a No Compete clause in our contracts but we have found that this fairly open nature between us and the client provides for a warm and fuzzy feeling. Our clients continued relationships with us is one born from respect for a job well done at a reasonable cost, not one out of fear that tomorrow the lights are going out and they won't be able to turn them back on.

    THis is however one of the reasons we avoid using third party controls mostly because of the fact that these controls do not usually share the same ideas on distribution, and we don't like telling the customer Oh By the way you have to buy XYZ as well as pay us X amount.

    We strive for the apps being supportable but not to easy to foul up. Overall though we have found that .NET is just what the doctor ordered.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.