What are the improvements in vb.net compared to vb6 that make developing such an application easier?
I can think of a few:
ADO.NET is better than ADO for data access (and more options such as the Entity Framework, data repository blocks, LINqtoSQL)
better ability to structure your code for ease of maintenance because of better support for object oriented programming
better testability
overall a much better IDE
better handling of XML
richer set of interface choices: silverlight, WPF, WinForms, WebForms, ASP.NET MVC,
Web Client Software Factory
ASP.NET allows you to divide your interface code from your business logic much better by moving the logic into the code-behind file: better separation of concerns leades to easier and cheaper maintenance costs
WinForms has a much richer set of controls allowing you to build apps that are much easier for your users
better integration wilth other Microsoft products such as Sharepoint
This is by no means an exhaustive list. But it's at least a good starting point.
I switched to VB.Net because of LINQ. Everything else was a nice bonus. ^^
The ability to use the farking scroll wheel on my mouse in the IDE!
Sorry, had to vent on that one since I've recently been stuck in VB6 for maintenance on a legacy app.
Related
I was thinking of have my wcf interface in its separate assembly and then the data/business logic in it's own assembly. Is this over-architecture or is it just fine? Does it make updating the services easier? or if their is an issue/bug, does it make fixing the bugs easier.
This is a good way to design your program.
This allows you to focus on business logic or display logic independently, which is called Separation of Concerns and is one of the most important principles in the development of quality software.
This doesn't help with "fixing" bugs so much as it helps in avoiding bugs altogether.
It also allows you to create different front-ends for the same business objects, just in case you would also like to have a scriptable Console interface or a web or Silverlight interface later on.
I have come to know that there is a code migration wizard, that heps migrate from vb6 to vb.net.
How I can access that in vb2008?
Thanks
Furqan
There seems to be some tool support available.
Still, I would be skeptical to the use of the word migrate if you are making the technology monster-leap from VB 6 to .NET 4.0.
If your VB 6 application is really well designed with core business logic nicely isolated in separate classes, then those parts could perhaps be suited for migration.
But, if someone intends to support and maintain this app for another 10 years, you should consider whether a rewrite is a better option. That way it will be easier to start taking advantage of the efficiency gains provided by the new technology. I don't think there is any migration tool that will convert VB 6 code into e.g. anonymous methods, lambda expressions, linq, reflection and generics.
The need to consider a rewrite is particularly important if your long-lived application has suffered increases in code entropy and complexity over the years causing it to be hard to understand and difficult to maintain.
We are migrating our applications to VB.Net 2008 from Classic VB and I need to create a base namespace and business layer. My method of approach is going to be to visit our top BA and identify the common areas of our (Fixed Income) company and try to form a decent inheritence model with as much of the code in generics as possible.
What's everyone's experience of doing this and also as a second part of the question, we are looking at incorporating Web Focus into the OLAP side, how would this affect the design of the corporate namespace and it's derivatives?
I think the best way to begin to create a corporate .NET framework is to begin by harvesting existing code out of current corporate projects. Building a framework from scratch by talking to a BA without writing code for a specific, concrete project might lead you to over design the framework in some areas and totally miss some necessary features in others (as well, it might place artificial constraints on your framework clients for no good reason).
See Fowler's entry on Harvested Framework and this blog post for a more complete explanation.
I'm not familiar with Web Focus but I'm guessing it would affect it in some way, however, if you go with a Harvested Framework, your usage of it in the first few applications you build will shape how you use Web Focus within the framework.
Jereme has it right on the framework. I'll briefly mention something obvious about namespaces.
Always remember what a namespace is for - it's to provide a "space" in which names will live. In particular, it's meant to provide a space small enough that the people creating names within that space will be less likely to produce duplicate or confusing names.
This can only work if the namespaces are organized along patterns of organization, or of domain knowledge. A simple example often used is a pattern of Company.BusinessUnit.Application. The theory is that within the set of developers working on a given application, there is less chance for name duplication. This will not be true for a large application, where you would want to break it further based on layer or area. Similarly, of the business unit is too large, you'll want to break that down.
But in all cases, you're really trying to partition sets of brains, as it's the brains that create the names.
If your application is under VB6 (not VB3) then I strongly recommend that do the redesign to a class hierarchy in VB6 first. The reason for this is that in any conversion you try to preserve the behavior of the old application. Is stretches out the project time to do this and do a redesign at the same time.
By making the design changes in the applications original language first then you are assured that any bugs that result are due to the design not the conversion.
I done three major conversions of our software in the past 20 years; (DOS to VB3) (VB3 to object oriented design in VB6) and (VB6 to VB.NET).
Finally it is straight forward to make a design in VB6 that is ports over to VB.NET readily. The trick is to hide the specific VB6 APIs and constructs behind a interface (graphics, printing, etc)>
When do the conversion I recommend working from the top down. Change over your forms first to .NET which calls the VB6 COM DLLs. Then convert each layer over until you reach the bottom DLLs.
Again, if you try to change the design AND convert to another language for any complex application you will double the conversion time.
I work for a large state government agency that is a tad behind the times. Our skill sets are outdated and budgetary freezes prevent any training or hiring of new employees/consultants (firing people is also impossible). Designing business objects, implementing design patterns, establishing code libraries and services, unit testing, source control, etc. are all things that you will not find being done here. We are as much of a 0 on the Joel Test as you can possibly get. The good news is that we can only go up from here!
We develop desktop CRUD applications (in C++, C#, or Java) that hit the Oracle database directly through an ODBC connection. We basically have GUI's littered with SQL statements and patchwork code. We have been told to move towards a service-oriented n-tier architecture to prevent direct access to the database and remove the Oracle Client need on user machines.
Is WCF the path we should be headed down? We've done a few of the n-tier application walkthroughs (like this one) and they seem easy to implement, but we just don't know enough to understand if we are even considering the right technologies. Utilizing the .NET generated typed DataSets seems like a nice stopgap to save us month/years of work (as opposed to creating new business objects from the ground up for numerous projects). Is this canned approach viable for a first step?
I recently started using WCF services for my Data Layer in some web applications and I must say, it's frustrating at the beginning (the first week or so), but it is totally worth it once the code is deployed.
You should first try it out with a small existing app, or maybe a proof of concept to make sure it will fit your needs.
From the description of the environment you are in, I'm sure you'll realize the benefit almost immediately.
The last company I worked for chose WCF for almost the exact reason you describe above. There is lots of good documentation and books for WCF, its relatively easy to get working, and WCF supports a lot of configuration options.
There can be some headaches when you start trying to bend WCF to work in a way not specifically designed out of the box. These are generally configuration issues. But sites like this or IDesign can help you through those.
First of all, I would definitely not (sorry for the emphasis) worry about the time you'll save using typed DataSet's versus creating your own business objects. That is usually not where you will spend most of your development time. I prefer using business objects myself.
In you're situation I would want to implement a proof-of-concept first. One that addresses all issues you may encounter. This proof-of-concept should implement an entire use case, starting on the client, retrieving data from the database and returning it to the client. You should feel confident about your implementation before continuing.
Then about choice of technology. WCF is definitely a good choice for communication between your client applications and the service layer. I suppose that both your clients as well as your service layer will become C# applications? That makes things a lot easier since interoperability between different platforms (Java/C# for example) is still not trivial although it should work in most cases.
Take a look at Entity Framework (as there are a couple Oracle providers available for it already) in conjunction with .NET 3.5 SP1 which enables built-in WCF serialization of your EF generated classes.
Here is a good blog to get started: http://blogs.msdn.com/dsimmons
CSLA might be a good fit for your N-Tier desktop apps. It supports WCF, has a large dev community, and is well documented. It is very object oriented.
What are the opinions of the software developers who have used Spring.NET and NHibernate in their projects? In couple of our projects in the company where I work, we have used these third party tools very extensively and we have gained tremendous productivity. A little caveat is that it is a little challenging for junior .Net Developer to grasp the concept.
Imo, Spring.Net and NHibernate go hand in hand: If you master the learning curve you will be very pleased when Spring is used for (almost transparent) transaction handling for NHibernate, Dependency Injection as well as Db:Provider handling.
NHibernate (or similar ORM's) can be extremely helpful with "greenfield" development, where the domain object model can be designed properly, and then the database schema and NHibernate mappings can be code-generated to match the model. On the other hand, NHibernate can be very tough to apply to a legacy or poorly normalized database. Although it has support for handling some unusual data structures, the learning curve is much higher for those techniques.
I can't say much about Spring.Net except that in 2007, our team tried to implement it into an existing, complex solution to handle DB transactions and entity validation, but we scrapped the idea after a week of work. Our resident Spring/Java expert concluded that Spring.Net was a couple versions behind Spring and wasn't mature enough to handle the use cases in our project. Disclaimer: not sure what version of Spring.Net that was, so things may have improved recently.
There has lot of benefits using spring.net/nHibernate.
For data access you are able to take full advantage of nHibernate ORM with lazy loading, database independent programming, easy save load update delete your entities. No need to write any query to do that. That is why after designing a database and after development if any change is required at any state of development it is very much easy to change.
Dependency Injection(DI) helps to separate the UI and business logic. That is why any time you are able to change your graphical user interface without breaking any business logic. Same way if you need any change at business logic then need only build business layer. And it is also configurable.
Aspect Oriented Programming (AOP) is another feature of Spring.Net. It helps logging application, dynamic method interception allow more control over method call. It makes easy to authorize application. Declarative transaction management is a nice feature to manage transactions. You do not need to write code for start stop database connection. Just write at configuration file at which method you want to maintain transaction. So at large scale project it will save lot of time and will give you more flexibility over transaction management.
Spring webservice is very easy to write and consume from a client. Not need to add any custom attribute, no WSDL. You can intercept every method call, you are able to add advice like logging advice, authentication/authorization advice.
Overall it save approximately 33% of development time, make application more maintainable, highly configurable.