Opinion on possible architecture
-
I'm still debating this one, I'd like to keep going with doing MFC development (since I think that is likely to do me better with regard to future employment after graduation etc.). I was originally going to do some data access code in ATL, as well as a few Office add-ins. I am now considering writing these in C#. The add-ins were going to use the data access code to read and write to a data store. Originally, the data access code would've been written in ATL as a COM server, but I am now considering writing it as a .NET assembly registered in the GAC. Thus enabling the same data library to be used by all constituent parts. The other part is a regular client. At first thought the whole thing was going to be C# based, but I am now considering doing a mixture, with the add-ins and data access code in C# and the main client in Managed C++ -- predominantly MFC but making use of the managed extensions to access the data access code (which will be deployed in the GAC). Does this sound like a decent thing to do? I'm really keen on developing the client with MFC and was originally going to just dive in with ATL and see where I surfaced. However, if I can accomplish the same thing in C# by using .NET assemblies (with a tiny learning curve) why not? :) Considering the majority of the client code will be regular C++ based, with only bits for data access using the managed extensions, will I get almost regular performance, and would this ever be a concern anyway? Thanks, Paul
-
I'm still debating this one, I'd like to keep going with doing MFC development (since I think that is likely to do me better with regard to future employment after graduation etc.). I was originally going to do some data access code in ATL, as well as a few Office add-ins. I am now considering writing these in C#. The add-ins were going to use the data access code to read and write to a data store. Originally, the data access code would've been written in ATL as a COM server, but I am now considering writing it as a .NET assembly registered in the GAC. Thus enabling the same data library to be used by all constituent parts. The other part is a regular client. At first thought the whole thing was going to be C# based, but I am now considering doing a mixture, with the add-ins and data access code in C# and the main client in Managed C++ -- predominantly MFC but making use of the managed extensions to access the data access code (which will be deployed in the GAC). Does this sound like a decent thing to do? I'm really keen on developing the client with MFC and was originally going to just dive in with ATL and see where I surfaced. However, if I can accomplish the same thing in C# by using .NET assemblies (with a tiny learning curve) why not? :) Considering the majority of the client code will be regular C++ based, with only bits for data access using the managed extensions, will I get almost regular performance, and would this ever be a concern anyway? Thanks, Paul
Paul Ingles wrote: with the add-ins and data access code in C# and the main client in Managed C++ -- predominantly MFC but making use of the managed extensions to access the data access code That's precisely what I did in my N-Track work-time tracking system. That way you can use MFC for all the GUI stuff and you can also use your __gc classes to access the .NET stuff :-) Nish
Author of the romantic comedy Summer Love and Some more Cricket [New Win] Review by Shog9 Click here for review[NW]
-
I'm still debating this one, I'd like to keep going with doing MFC development (since I think that is likely to do me better with regard to future employment after graduation etc.). I was originally going to do some data access code in ATL, as well as a few Office add-ins. I am now considering writing these in C#. The add-ins were going to use the data access code to read and write to a data store. Originally, the data access code would've been written in ATL as a COM server, but I am now considering writing it as a .NET assembly registered in the GAC. Thus enabling the same data library to be used by all constituent parts. The other part is a regular client. At first thought the whole thing was going to be C# based, but I am now considering doing a mixture, with the add-ins and data access code in C# and the main client in Managed C++ -- predominantly MFC but making use of the managed extensions to access the data access code (which will be deployed in the GAC). Does this sound like a decent thing to do? I'm really keen on developing the client with MFC and was originally going to just dive in with ATL and see where I surfaced. However, if I can accomplish the same thing in C# by using .NET assemblies (with a tiny learning curve) why not? :) Considering the majority of the client code will be regular C++ based, with only bits for data access using the managed extensions, will I get almost regular performance, and would this ever be a concern anyway? Thanks, Paul
Paul Ingles wrote: Does this sound like a decent thing to do? It ofcourse depends on the type of application and the intended audience. If you are doing for fun you can do whatever you want to. If only dataaccess componenets are to be written in managed c++ have a look at ADO (or OLEDB consumers templates). If the majority of code is unmanaged and only a small majority is managed I will prefer to have a fully unmanaged solution. However if extensibility is a consideration managed solution may be considered. Step back, rub your eyes, take a deep breath, stretch a bit, and reflect on the relative importance of CP, CG, the age / travel time sustained by supposedly 'fresh' cheese curds, and Life in General. - Shog9
-
Paul Ingles wrote: Does this sound like a decent thing to do? It ofcourse depends on the type of application and the intended audience. If you are doing for fun you can do whatever you want to. If only dataaccess componenets are to be written in managed c++ have a look at ADO (or OLEDB consumers templates). If the majority of code is unmanaged and only a small majority is managed I will prefer to have a fully unmanaged solution. However if extensibility is a consideration managed solution may be considered. Step back, rub your eyes, take a deep breath, stretch a bit, and reflect on the relative importance of CP, CG, the age / travel time sustained by supposedly 'fresh' cheese curds, and Life in General. - Shog9
It is going to serve a couple of purposes, firstly give me more experience developing a proper software application (as opposed to programming/software development theory that I've covered at Uni. Originally, the idea for the application came from my Uncle, who wanted to do something, but didn't know of any existing software package that would do what he needed -- so I took it up as a bit of a part-time project. I'd imagine that the majority of the code would be unmanaged, and ideally I'd just go with MFC and ATL. However, developing COM servers in ATL appears a little daunting, so I thought about delving into Managed C++. I prefer the UI functionality in MFC, as well as the stricter Doc/View architecture. However, the .NET framework encompasses all the "other stuff" pretty well (from what I've seen through developing the odd C# app and ASP.NET app), so it seems an ideal solution. All I've got to do now is pick up a copy of VS :)