This might seem like a ridiculous question since I'm quite inexperienced in .NET.
Is it possible to build components in C#, using .NET, which can be reused in ASP.NET. For example if one would like to port an application onto the web.
If possible, how portable are they? I.e. can GUI be reused in some extent? Is there an intermediate format to use as base or is it required to use C# components as binaries?
Thanks.
Edit:
Thanks for your input! I'm quite familiar with the design aspects of this problem, i.e. how to model components for reuse. However you made me realize that the question really is about - To what extent is .NET reusable between ASP and Windows? Can one say that certain packages of .NET components are independent of environment and some are platform specific?
Absolutely - a .NET class can be used in any kind of .NET application. However, it kind of depends on what part of the application you're talking about.
Generally, Windows Forms user interfaces are NOT reusable as ASP.NET user interfaces, because the design constraints are so different (i.e. web browsers only support a small number of controls, often use flow (not grid) layout, etc. Similarly, the events are different (a web form button isn't the same as a windows form button, etc.).
What you can reuse easily, though, if you do things correctly, is the business logic. Design your classes so that they don't internally know anything about whether it's a windows form or a web form (or a console application, or web service, etc.). That is, the classes should be pure implementations of your business logic. Then you can use those classes in any context you want to.
The short answer to your question is yes - simply separate out the code you want to share between the two views into a interface-independent class, preferably in a separate assembly, and include that assembly.
The long answer is more complicated - the ability to do this will vary between application and application. You'll be able to separate out less code for UI intensive applications that don't do much behind the scenes (such as, say, some sort of graphics game), than you will for a very simple UI application that does a lot behind the scenes (say, a UI that consists of a single button that then kicks off a complex data manipulation process).
In the end - .NET provides the ability for you to do this. Your actual ability to do this will be very dependent on your own design abilities and your particular requirements. There's a lot of writing available on this subject - I suggest starting by taking a look at Design Patterns (though the original book writes examples in C++, I believe that someone has done a book with examples in C#. I cannot, however, speak to the quality of it.)
I've never done it before, but i guess you can place the common code on a separated class. UI will need to be duplicated as windows forms and asp.net have completely difference programming approaches.
Related
I have three programs (one in C++ + WinAPI, another one in C# .NET and the last one in Java) with different functions. I am about to choose one and implement functions of the other two. Is it possible to somehow merge them? I need to have them in one GUI, under one process (at least visually). IPC isn't a problem.
Thanks for anything
I think the best/easiest thing you could do is make the GUI only in C#, in windows clients you could use Windows Forms or WPF, in web based you can use ASP.NET WebForms or ASP.NET MVC.
in all these cases except MVC (Razor) you have really good tools for designing and customizing the GUI within Visual Studio.
Your C++ code can be wrapped in a class library or as you say accessed via some kind of IPC if it has to run as application, same for Java but if you are 100% free to write and re-write things you could also imagine to port the Java code to C++, this could be easy, difficult or impossible depending on what the java code does.
at last resort if both C++ and Java applications must stay separated and must run in background on same or another machine and you still want to consume their services or methods from your C# GUI, as you mentioned, IPC is probably the way, not sure what you can do in Windows with Java and IPC, surely java can expose or consume XML web services.
The problem you will find is that each has its own process model, and you either need to get the process models to coexist or you'll need several communicating processes (though the user need not see them). With Java, eg, it can be "king", or you can set up a sort of sub-process in another process, or you can have it set up/take down its process model on every call. Which approach is best depends in part on the complexity of the operations you'll be doing in the "guest" language.
The one main thing, though, is that only one language can control the UI -- in general different language UIs don't coexist, and I doubt that you can have eg, a Java UI object in a C# GUI, at least not without treating it as a foreign window.
If you're talking about the best language to rewrite the programs in, that depends entirely on the primary function. If you mainly need it to integrate with Windows nicely, C# would be the obvious choice. If your main idea is to make it cross-platform, it'd make most sense in Java.
If you're talking about running them together and using IPC then yes, that's possible too - you could use anything from a fully blown IPC framework to a custom protocol over sockets on localhost. There shouldn't be too much of an issue there, though remember depending on how big the parts in other languages are, it may cost just as much in terms of time to rewrite them (and there's less of a maintenance burden that way too.) There's also complexities with controlling GUIs from other processes, it can be done ish by passing native canvas IDs around cross process, but it's hard to get working properly, may not be particularly safe and makes it quite difficult to work out what's going on from a maintenance perspective.
I was asked to create a stand alone application from a web app - I have to keep the same look and feel and of course the functionality. Basically, the end result should be the following: a standalone product that looks and does exactly the same thing as its web - based counterpart.
I have been developing for some time with asp.net and c#, but I doubt this is easy to convert to a standalone C# application.
I heard some stuff about xaml - but I am not sure what to use to make my life a little bit easier.
Should I just leave the .Net platform and turn to Java? Or if I keep the .Net what should I use?
better to keep in .net as it would be easier to migrate the code.
and .net is better than java in terms of desktop apps.
Web and desktop apps are fundamentally quite different (as much as ASP.NET Web Forms developers would argue to the contrary), but you should be able to reuse a lot of your business logic (especially if you separated your concerns properly). I'd suggest starting with a new Windows Forms project, building out an equivalent set of controls (buttons, grids, etc), and then looking for opportunities to borrow UI logic (click events, etc).
If your web app is written in ASP.NET, then I would stick with that.
If your web app was built properly and the new app has to have the exact same functionality, then you should be able to re-use most of the code whether you use WPF or Windows forms. You would just need to rebuild the UI.
Keep the .Net code and see how much you can reuse. Tell that you can't make the user interface look and work exactly the same and that there will be a lot of minor and some major differences. Add that the look and feel will be the same with added functionality.
See if you can reuse the basic data loading code. Then simply create a form/panel/tabpage for each page in the web application and see what you can reuse.
Or easier yet, create a simple windows application using a browser window and simply point to the existing app.
We have a ten-year-old ASP application that we are considering planning an update for. We want to take advantage of the new technologies that ASP.NET has to offer, as well as the opportunity to fix some issues with the existing framework (the existing code-base is highly fragmented, nearly impossible to test, let alone debug, and the entire application appears to have been constructed according to the "Farmhouse Pattern".)
To that end, it seems that the time has come to rebuild this application. But, we are a small business, and we simply don't have the resources to either hire out the rebuild, nor to dedicate our small team of developers solely to the task of rebuilding (we've got other tasks on our plate, and can't concentrate on this one particular task for the length of time it would take to fully reconstruct the application).
What, then, are some useful strategies we can employ to help us convert this app, without having it consume all of our limited resources for the duration of the re-write?
Sounds like an interesting challenge. It's definitely not going to be easy, especially if you can't dedicate any resources to the project full time.
If you have a 10 year old application that is working, I would suggest not going for a complete re-write at all. I would start by sitting down and figuring out what you want your end product to be.
Is it going to be an ASP.NET MVC Web Application, an ASP.NET WebForms App, or something else? Once that decision is made, come up with a loose design for an architecture. If you do things correctly, you can build out bits and pieces of the business logic in .NET and utilize it from your Classic ASP code until you're ready to re-write the UI in .NET as well.
I agree with what Justin said; if you have a working application in place, you'll need a compelling reason (i.e., money) to justify the expense in rewriting the application for a new platform.
Although ASP classic and ASP.NET share a similar-looking syntax and some common coding conventions, they are very very different from each other. If you tried to simply copy-paste classic ASP code into an ASP.NET application, you might be able to get it to work, but you'd be missing out of a lot of the advantages of ASP.NET Web Forms or ASP.NET MVC (and their respective frameworks, of course).
You can, however, extend the functionality of the existing site with .NET code through web services or COM interop. We have a 10+ year old classic ASP web site and I've used both .NET web services (.asmx) and COM-callable .NET DLLs to enhance our existing application. In both cases, I wrote all of my new business logic in the .NET component and provided a chunky interface to work with the existing ASP page. That allowed my .NET code to be very easily testable and still use our existing (huge) investment in our classic ASP site.
The only approach that has worked for me is to carve of areas of functionality in small slices, and rewrite. "Converting" first, then refactoring seemed like a good idea a few times, but in the end just became horrible messes of code written in ASP.NET instead of ASP - and that added no value.
If you have a site that has distinct areas of functionality, carve one off and start with that (I chose "contact us"). Write it the way you think it should be written - that is, assume your new part is fitting into the end design of your well-written app. If you have to add "hacks" to interface with the old system, make sure they are isolated and commented.
When working on an update, think "can I carve of some of the functionality here into it's own bit?" - if so, convert it then update it. I found that if you insist on keeping the NEW app clean and allow yourself to add small hacks to the OLD app for communication, you get the best results.
This does mean you'll have two separate apps (two IIS web apps) for a while, and can make cookie/url and session management a bit hairy, as well as adding one more deployment concern. To combat this, make sure that you minimize state in your web app (always a good idea anyway), and share state through something other than Session.
If you do this a piece at a time, make the pieces small enough, and have a good design up-front, this works well - at least in my experience, it's the way that works best. Note that my experience may not match reality.
I created a Windows Form executable in .NET 3.5 that uses a dll to communicate with a machine that scans checks. I'm eventually going to need to move from an executable to a Web Form that can do the same thing. This will be months from now, but I wanted to start doing the research now as I have not done this before. I'm going to need to use ActiveX in order to communicate with the device via a Web Form. I've also not done this before.
I'd like to keep the functionality of my existing executable without having to rewrite most of it, although I do understand that some of it will need to be rewritten. I've done research on ActiveX and how to use it, but I wanted to know if someone has had a similar situation as this. What did you do to convert an exe to a web program? Are there good, specific sources out there that I'm overlooking that can point me in the right direction for this situation? Is there any advice that you can give from your experiences that can help me to reduce mistakes? The company that I work for does not have anyone else here that has done this before, so I've got to teach myself everything needed to do this.
Thanks in advance.
This is where separation of concerns and n-tier design shine through. Hopefully your UI layer is loosely coupled from your domain model. If this is the case, you can code a second IU layer for the web. And not have to change your domain model at all. Then you can compile for each scenario.
*note - In practical use I have always had to extend my business domain to account for some issues with the second UI, but those modifications have usually been minor, and have pointed out places where I had coupled too tightly anyway.
Another option you may consider is creating a web services layer over your business domain code. And then coding a web application that communicates with your domain model via those web services calls. This may have performance implications, and would not be my preferred method of accomplishing this. Though you may find it more manageable if you don't have a well designed application to start with.
"I'd like to keep the functionality of my existing executable without having to rewrite most of it"
In general if you extract as much logic as possible into its own assembly/dll, you can reuse that from whatever UI framework you want. Just make sure you're not doing anything UI specific in there (throwing up dialog boxes, etc).
Normally, converting winforms to webforms is quite possible, although typically a slow development process. Even if you've got the cleanest domain layer in the world, the fact that objects in your web page are thrown away every time means that a web domain layer is normally written very differently to a desktop domain layer.
However, in your case the device - server communication is going to be extra difficult.
Have you looked at xbap? It's basically a way to deploy WPF applications into a web page. It requires your clients to have the right version of .NET installed, but it's going to be the easiest path for you, especially considering that you can host winforms in WPF...
You may take a look at Silverlight 4,
http://silverlight.net/getstarted/silverlight-4-beta/
It contains many features that ASP.NET Web Forms hasn't.
If your team can accept something like ActiveX, why not Silverlight 4? The only disadvantage is that SL4 is still in Beta.
What are the fundamental techniques to make most part of my C# source code UI independent?
For example, I would like to write my source code for Winforms desktop application which I shall be able to plug into asp.net web application or a WPF application with very minor changes. I.e. I shall be able to use the same source code irrespective of UI technology to make it future-proof.
I know CSLA framework can do that.
But if I don't use CSLA (it takes some time to learn a new framework and at present I don't have that much time to spend on it), what points should be taken care of to achieve this kind of ability in my C# code?
Can you give me an example? I already use Business Objects and layering technique in my applications. But even so I have seen that it needs a lot of coding to plug my code to new UI technologies.
Please do not provide me with any superficial answer.
The best way to do UI independent coding is to seperate the logic from the presentation. Take a look at the MVC pattern.
This is more of an discipline issue with your design rather than a framework issue. A framework can't not force you to design properly. It can make things easier for you if you design the app properly, however there are always ways around the enforcement of it.
To make your code UI independent, put the logic that is not dependent upon UI into a separate layer or assembly. Separate logic from presentation. It's what all the patterns like MVC, MVP, and MVVM follow. It's such a fundamental piece of software structure that it should be ingrained upon you; if it's not, make it so.
Separate logic from presentation. Learn it. Live it. Love it.
Edit:
Can you give me an example? I already use BO and layering technique in my applications. But even so I have seen that it needs a lot of coding to plug my code to new UI technologies.
Please do not provide me with any superficial answer.
I see that you have edited. Allow me to elaborate:
There's no getting away from some logic that is UI-dependent. UIs are not a shell; they still have logic and functionality. But that functionality should only be geared toward user interaction. Display data. Gather data. Fancy graphical tricks and animations, if your preferences lie in that direction.
The rest goes to the business layer, and that stuff can be reused. If you layer properly, you can avoid having to rewrite your core functionality every time you write the program for a new UI framework.
But you still have to rewrite the UI stuff.
If you're building a multi-tier application, your business logic, data access, etc should already be separated into classes that are completely independent of your UI. Repurposing those libraries for a different target platform - desktop vs web, etc - should be a simple matter of referencing your existing libraries from your new application.
This is a fundamental rule of software development. Although patterns and frameworks like MVC, etc enforce this more stringently, it's ultimately up to you to design your application correctly. This sort of task doesn't require learning a new technology - just common sense and a tiny bit of experience.
Check out Martin Fowler's excellent article on this topic.
GUI Architectures, Including MVC, MVP, MVPC
Take a look at the explanation of MVVM(Model-View-ViewModel) at MSDN Magazine. MVVM is widely used for WPF application development.