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.
Related
There is plenty of documentation out there that talks about design patterns (e.g. Visitor), SOLID (Single Responsibility etc), KISS (Keep it Simple, Stupid), tiered design etc.
One thing I don't fully understand is how to decide when a new project/DLL is required when extending an application. Is there any criteria that is used?
For example, System.Windows.Forms (http://msdn.microsoft.com/en-us/library/system.windows.forms.containercontrol.aspx) is part of System.Windows.Forms.dll yet it derives from System.MarshalByRefObject, which is part of mscorlib.dll.
You're mixing up assemblies (DLLs) and namespaces.
Assemblies are the binary files which contain the implementations of classes, etc.
Namespaces are just a way to organize classes, enums, etc. into logical groups, to prevent from having every class accessible from every level, and prevent naming conflicts (eg. System.Windows.Forms.Timer and System.Threading.Timer).
System.Windows.Forms doesn't derive from System, and System doesn't live solely in mscorlib.dll. Anyone can put anything in the System namespace - even you could do it. It's just a sub-namespace of System.
There are several reasons for breaking a subset of code out into a separate assembly. A big one is re-usability. If you have some common controls or utilities, you can maintain it in its own DLL and use it across projects without copy-and-pasting of code.
Don't confuse tiers with layers. Layering your code is almost always a must. Splitting your code out into separate physical tiers, however, is something that you usually don't want to do until you actually need to (following the KISS principle).
If you layer your code properly, then when the time comes that you need to break it out into separate tiers, doing so should be a very painless process. If, however, you never layered your code properly you'll find that splitting out the tiers will be very difficult.
As a simple example, lets say you create a login form and lets say you put all the logic to gather the system information, access the database, validate the user credentials, and build the permissions, all directly into the WinForm class. The code I just described has only 1 layer and it has only 1 tier. If you then found yourself needing to create a web-based login page using ASP.NET, you would find it very difficult to reuse that existing code. With the web based login, you'd want to at the very least, separate the UI logic from the business/data access logic, but because it's all directly in the WinForm class, it's all unusable without re-factoring the code.
Now, let's say, instead of putting all that code in the form, you took the time to layer it properly. Let's say you broke out all of the code that accessed the database about put it all into data access classes. And then you put all of the business logic code put it all in business classes. At that point, the actual code in the WinForm class should be limited to doing nothing but UI related logic such as handling control events, setting labels, etc. In this second example. you still only have 1 tier, but you have three distinct and independent layers (viz. UI, Business, Data Access).
If you had already layered your code like that, then when the time came that you needed to reuse it in the web-based project, you could easily move the business and data access layers into a class library (dll) and then reuse them in the ASP.NET project for the server-side tier.
Breaking your code into separate class libraries is only typically necessary in two situations:
You need to reuse the code in multiple projects
You need to divide your project into multiple tiers
Even if you put all your code in a single project, as long as it is well-layered, it will be very easy to split the project up into multiple class libraries when such a situation arises. So the big design issue is not how many DLL's you have. Rather, the big design issue is how many layers you have. Once you have the code layered, it will be easy to move it around between different projects as necessary.
In practical terms, even when you don't need to reuse the code between projects nor support n-tiers, you may still legitimately choose to divide your layers into separate class libraries. It may make sense to do so purely for organizational purposes, or for consistency. For instance, if another developer comes behind you and sees classes in a class library called "MyCompany.Feature.Business", they can safely assume that those classes are all part of the business logic layer. In that way, breaking your code up into separate class libraries can be self-documenting.
There are other reasons too, for putting code in dlls. For instance, it makes it easy to support plug-in architectures or to make it easier to update one part of the application at a time.
I'm writing my first WinRT app for Windows 8 in C#/XAML managed code and I obviously have to handle the UI in the different sizes and orientations that could occur (FullScreenLandscape, FullScreenPortrait, Filled and Snapped).
Most people seem to suggest handling the UI changes through the Visual State Manager in XAML, however me being more comfortable with writing the code-behind rather than XAML, I thought I would simply handle the Current_SizeChanged event with a switch statement for each of the states.
I tried both ways and both seem to work for me (though the VSM was decidedly more work - at least for me).
Can someone tell me why I should use the VSM over code, or what benefits I would receive?
It's a good question, and certainly one that entered my head when starting WPF & WinRT development. Having coded C# projects for years, it seemed a strange concept to start building UI logic in the Xaml (which is usually more lines than C#, but also more declarative).
In actual fact (if you don't mind me saying) I think we can abstract your question out to 'Is there any benefit to writing UI code in Xaml over C#/VB.net?'.
Let me give you an example, in work I'm on a project team with several developers, and several graphic designers. The designers are pretty awesome at laying out that Xaml, and creating a consistent feel for the application (something I can't say I would be that good at) - but will have little idea when it comes to writing web-services and Data Access layers - which is our job as developers. And that's how it should be right?
Well whenever you start writing a lot of View/UI related logic in C#.net, this can lead to all sorts of problems. The designers all of a sudden can't focus on the Xaml at hand, and must get up to speed with OO programming. In our project this isn't that much of a concern, as the designers are actually pretty competent developers (must have been all that UI code I forced them to understand last year :)) But what I think it boils down to is a 'Separation of Concerns' at a job description level. If we take the paradigms associated to WPF I think things like Databinding 'guides' developers down a road where they create separated, testable UI and Business layers - the same way that the nature of Xaml allows for a very declarative approach to writing UI where the View Logic is created and maintained in a very readable manner without getting too much into the nature of OO programming.
So, coming back to your question - No, I don't think there any immediate benefits, and if you come from a mainly .Net background to write a lot of these things is Xaml can be little tricky. However, if you are in a team of people - or if you find best-practices a very important factor in development, then writing View related code such as Visual State manager configuration in Xaml is the way to go.
One last point - you'll notice I used the terminology 'View related logic' a lot. This is because it's widly viewed that writing UI related code in code-behind is acceptable (if not best-practice) but sometimes due to the nature of the WPF or WinRT framework you are dragged down this route for some functionality. However, if you are writing business logic in the UI files codebehind this is viewed a particular no-no. This breaks the 'seperation of concerns' and can make testing very difficult. If you are following the MVVM pattern (as many WPF or WinRT projects do) then this is what the ViewModel is responsible for.
I am developing a VB6 legacy application. I have started writing all new code in VB.NET essentially creating what I am calling an interoperability layer. I could approach this in two ways:
Write all new code in VB.NET using this interoperability layer and use a phased approach to upgrading.
Continue writing VB6 code and then convert it all at a later date (use a big bang approach). I do not have time to convert the entire application at the moment.
My question is, which is the better approach?
UPDATE
The reason I favour option 1 is because there is an ASP.NET application. The previous developer would effectively duplicate code in both apps i.e. VB6 and ASP.NET. Therefore some of the code in the ASP.NET app can be shared with VB6 and vice versa. That is why I believe option 1 is better, but I cannot find any literature to suggest that developers actually do this
In a previous life I was involved in the same type of project. The original application was written with Access as it's framework. Then came VB6 which seemed to work nicely and allowed for more features without having to alter much of what was written originally in Access.
Along came .Net ...
...as much as I disliked the developmental staging to .Net and being forced to work with an interoperability layer it was necessary.
That said, I will answer the question as subjectively as possible:
If you know that the application is to be converted fully to .Net, then do as much of your new development with .Net as you can. There is no reason I can think of to put it off other than the perceptions (and truths) about interoperability - e.g. more overhead, performance, etc.
sidebar - at least you don't have interoperability issues with Access ...when it crashes, it brings down everything. It was my first experience with interop (with Access) and it wasn't pretty.
Advantages to waiting on .Net development:
shorter time to deliverable (no interoperability layer)
more stable app (no interoperability layer)
Disadvantages to waiting on .Net development:
Long (and likely unprofitable) release cycle while the entire app is re-written
Lots of new bugs introduced
Learning to write unit tests when that will be the last thing on your mind
Beginning .Net development now will increase your chances of success in the long run. I don't believe an interop layer is going to cause you the headaches it did for me - and any degradation in performance should be minimal.
I don't know if you are involved with a team of developers on this project, but if you are, make sure everyone is on board with the move to .Net. I've seen a few VB6 developers strike a dear in the headlights pose over VB.Net. The nature is to continue writing in the same style they're used to.
Concentrate on giving the users what they want.
If it's easier to accomplish this in vb6, then do that.
Worry about converting to vb.net when it's necessary to convert to vb.net.
The tools to convert vb6 to .net are now pretty
good, are under constant development and so can be expected to improve further.
I personally would use your first option(since you already have your interoperability layer implemented), that way it will make the rewrite when you do it less painfull.. if you design you class structures correctly. The second option would be my preferred way to go but since you are under time constraints, use the first. Eventually the VB6 runtimes are not going to be part of newer versions of Windows, see this SO question. I myself have a VB6 application that is going to need to converted.
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 do you suggest for Data Access layer? Using ORMs like Entity Framework and Hibernate OR Code Generators like Subsonic, .netTiers, T4, etc.?
For me, this is a no-brainer, you generate the code.
I'm going to go slightly off topic here because there's a bigger underlying fallacy at play. The fallacy is that these ORM frameworks solve the object/relational impedence mismatch. This claim is a barefaced lie.
I find the best way to resolve the object/relational impedance mismatch is to either use OOP exclusively and use an object database or use the idioms of the relational database exclusively and ignore OOP.
The abstraction "everything is a table" is to me, much more powerful than the abstraction "everything is a class." It takes less code, less intellectual effort and leads to faster code when you code to the database rather than to an object model.
To me this seems obvious. If your application is data driven then surely your code should be data driven too? Yet to say this is hugely controversial.
The central problem here is that OOP becomes a really leaky abstraction when used in conjunction with a database. Code that look perfectly sensible when written to the idioms of OOP looks completely insane when you see the traffic that code generates at the database. When that messiness becomes a performance problem, OOP is the first casualty.
There is really no way to resolve this. Databases work with sets of data. OOP focus on instances of classes. Trying to marry the two is always going to end in divorce.
So to answer your question, I believe you should generate your classes and try and make them map the underlying database structure as closely as possible.
Perhaps controversially, I've always felt that using code generators for the ADO.NET plumbing is fundamentally solving the wrong problem.
At some point, hopefully not too long after learning about Connection Strings, SqlCommands, DataAdapters, and all that, we notice that:
Such code is ugly
It is very boring to write
It's very easy to miss something if you're doing it by hand
It has to be repeated every time you want to access the database
So, the problem to solve is "how to do the same thing lots of times fast"?
I say no.
Using code generators to make this process quick still means that you have a ton of code, all the same, all over your business classes (or your data access layer, if you separate that from your business logic).
And then, if you want to do something generically (like track stored procedure usage, for instance), you end up having to customise your code generator if it doesn't already have the feature you want. And even if it does, you still have to regenerate everything all the time.
I like to do things once, not many times, no matter how fast I can do them.
So I rolled my own Data Access class that knows how to add parameters, set up and close connections, manage transactions, and other cool stuff. It only had to be written once, and calling its methods from a Business object that needs some database stuff done consists of one line of code.
When I needed to make the application support multithreaded database accesses, it required a change to the Data Access class only, and all the business classes just do what they already did.
There is no right answer it all depends on your project. As Simon points out if your application is all data driven, then it might make sense depending on the size and complexity of the domain to use non oop paradigm. I had a lot of success building a system using a Transaction Script pattern, which passed XML Messages around the system.
However this system started to break down after five or six years as the application grew in size and complexity (5 or 6 webs, several web services, tons of COM+ components, legacy and .net code, 8+ databases with 800+ tables 4,000+ procedures). No one knew what anything was, and duplication was running rampant.
There are other ways to alleviate the maintance then OOP; however, if you have a very complex domain then hainvg a rich domain model is ideal IMHO, as it allows for the business rules to be expressed in nice encapsulated components.
To answer your question, avoid code generators if you can. Code generators are a recipe for disaster, but if you do go with code generation do not modify the generated code. Also be sure to have a good process in place that is easy for developers to get the new generated code.
I recommend using either the following: ORM or hand roll a lightweight DAL. I am currently transitioning a project over to nHibernate off my hand rolled DAL and am having a lot of success; however, I like having the option of using either option. Further if you properly seperate your concerns (Data Access from Business Layer from Presentation) you can have a single service layer that might talk to a Dao (Data Access Object) that for one object is an ORM but for another is hand rolled). I like this flexibility as it allows to apply the best tool to the job.
I like nHibernate over a hand rolled DAL because while my DAL does abstract away most of the ADO.Net code you still have to write the code that takes a data reader to an object or an object and creates the parameters.
I've always preferred to go the code generator route, especially in C# where you can make use of extended classes to add functionality to the basic data objects.
Hate to say this, but it depends. If you find an ORM tool that fits your needs go for it. We wrote our own system in small steps while developing the application. We are using C++ and there are not that many tools out there anyway. Ours ended up being a XML description of the database, from that the SQL generation script and the basic object layer and metadata were generated.
Do your homework and evaluate theses tools and you will find a good fit for your needs.