A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
Over the next few months I'll be updating some old data-centric applications (VB6), then starting an ASP.NET project. reviewing my old code, I realize that I'm not very good at elegantly separating out the UI, business logic, and data access layers.
In the VB apps, sometimes I would handle it all directly in the UI event handlers.
Other times I would create collections in the UI and pass them to the data access layer (by ref)then use the data access layer to populate the collections. I ended up adding isDirty, isNew, and isDeleted booleans to the collection items to track whether to perform update, insert, or delete operations.
I could never figure out how to use batch updates when there was a business layer (which contained the collections) between the UI and the data layer.
Other times I would have the data access layer return a recordset to the calling function in the ui, and process the recordset directly in the UI. The business logic layer would perform operations on the data, but it didn't sit between the UI and the data layer if you did a data flow diagram.
Other times I used a mix of everything.
In short, I often had too much coupling between layers, (probably) unnecessary overhead, and an inconsistent strategy on how to handle and pass data between the layers.
I plan on reading Fowlers latest information archictecture design patterns book, but until I have the time, does anyone have sage advice on how to efficiently do this?
Sunday, December 12, 2004
Try looking at a code generator:
Sorry, I guess I should have given at least a short explanation. I think a code generator could be helpful for you because most of them are built to encourage the sort of layer (or "tier") separation you're looking for. Turns out that most of them focus solely on the data layer, but some can also generate code for your business logic layer. In any case, using one of them will get you a good start on keeping these different tiers separate. And there's plenty of information on them at CodeGeneration.net as well as on the individual sites and web forums of the different tools.
Read Fowler's latest book first. The "when I have the time" statement is false. If you implement, then read, then re-implement, you'll spend longer than if you read then implement. So consider the time spent sitting around reading as a justifiable project start cost - tooling if you will.
I don't know VB but what I figure out is you are looking at Model-View-Controller kind of design. I have faced similar problems while using MFC.
The way I learnt is I looked at the way frameworks like COCOA (Mac), Qt are designed. They provide a clear cut ways of using MVC.
My advice download Qt(since it free and available for all platform). Try out a couple of small tutorials. It requires very basic knowledge of C++ though. In any case look at the way how it works. Then try to visualize your design. it worked for me.
>>Try looking at a code generator:
That might not be a bad idea, but it's similar to how I got into this mess to begin with. I would read examples on the internet and everyone seemed to have a different way of doing things. I'm sure that half of the examples I emulated were total crap.
>>Read Fowler's latest book first.
>>The "when I have the time" statement is false.
Actually, you're at least half right. I shouldn't have said I don't have the time. I asked for it for Christmas, and I think it's sitting under the tree right now. In the meantime, I want to finish some of these modifications before the holidays.
>>I don't know VB but what I figure out is you are
>>looking at Model-View-Controller kind of design.
>>I have faced similar problems while using MFC.
I was in grad school last year, and I needed to pick a pattern to implement for a SW Engr class assignment. So, I tried modifying a small Winforms apps I wrote to use an MVC pattern. It's really a stretch in an event-driven form environment. I don't think it make the design any better, and it sure was a pain to implement. Trying to do MVC in VB would probably be even worse.
>>Have a look at http://www.lhotka.net/
Are you referring to the book shown on the page, or one of his many articles?
Yet another anon
Monday, December 13, 2004
We started doing this conversion (to a separate business-logic tier) a few years ago and we are still plugging away, though the lion's share has been in production for years now.
For a little context our app is used by stock broker types to trade stocks and so on.
When we started out we all had a very clear idea of how beautiful everything would be in terms of nicely encapsulated like API's 'Enter New Order', 'Change Existing Order' and so on. We tried to keep the UI as stupid as possible, with the idea that we could plug in an alternate later (at the time .NET seemed too iffy, so we did something else thinking we'd plug in .NET later).
The reality is that in our experience anyway its impossible to make a complex high-quality GUI without a ton of complexity and business logic in the GUI itself. There are just too many stupid little affordances people demand - silly things like disabling the Good Till date on an order when they pick 'Good Till Cancelled' and so on. (That's a VERY trivial example, but there are hundreds more, some much more complex).
Of course this chasm between original vision and ultimate outcome is common in software, but I still laugh every time I hear people talk about switching UI's like its a simple exercise. (Of course it may very well be if you are able to inflict a simpler GUI on your users).
"[Using a code generator] might not be a bad idea, but it's similar to how I got into this mess to begin with. I would read examples on the internet and everyone seemed to have a different way of doing things. I'm sure that half of the examples I emulated were total crap."
Good point. If you use a code generator then you're going to have to work within the framework of the code it gives you.
Still, if you do some enough research beforehand you should be able to find one that (1) generates good code and (2) generates code that you're comfortable working with. Plenty of information at CodeGeneration.net and in web forums, etc., for you to figure out which are good and which are not so good. Then go from there and actually try demo'ing a couple. IMO, you'll definitely want to use one for the data access portion of your code, because the code there is likely to be highly repetitive (i.e, same code structure replicated lots of times to give you classes for accessing the different tables, views, sprocs in database).
I would have to agree with Hebert. The code generation techiques would give you a good handle on it.
One thing I always try to tell people when they look at code generation is not to think of the generated code as the end code, but as a bootstrap to development.
Of course make sure that your code has comments on where you deviate from the generated code and why. Especially for the gui layer. Also the GUI layer would be something to try and bootstrap in a logical way. Most code generation tools allow you to customize a template of what the code looks like. It does get you thinking a bit differently then normal application design, but it is very powerful as a technique to increase productivity.
The code generation tools usually rely on some sort of model. So if you define your application model well enough the tools will work fairly well. Plus the creation of a tool to help you with your domain specific approach wouldn't be too bad either.
Monday, December 13, 2004
I write code generators using Classic ASP. I have one called the ADO Entity Class generator that could help you out.
All you need to run it is IIS and a Database table/view.
The classes I generate are based on Joel's Entity Class article for CityDesk (google it).
If you want my code generator, email me (it makes good classes for VB6 and any OLEDB/Client-Side cursor connection and uses BatchUpdate).
If your budget can afford it, get Fowler book "Patterns of Enterprise Application Architecture", it's worth every penny you pay for it. If you haven't been to the fowler website, he has a mini-catalog of the design patterns in his book. In particular look into the DomainModel pattern and DataMapper pattern.
Catalog of Patterns of Enterprise Application Architecture:
Jimmy Nilsson has a good set of articles (6 part series) on how to implement these patterns.
A Pure Object-oriented Domain Model by a DB Guy:
You may also want to visit his weblog for some more tidbits:
Tuesday, December 14, 2004
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz