posted
I am working on a suite of applications in the .NET framework to manage different elements of our company's business.
It's the largest project I've ever undertaken. It will be roughly 6 applications (3 windows apps, 2 ASP.NET apps, 1 MS office app) as well as all using common underlying objects and a single database.
Anyway, I've frozen the requirements gathering and specs for the project and the database is designed (to the best of my ability) to follow DB design best practices (resulting in about 35 tables in an SQL server) and models the information I need to store very well.
Of course, everything is still on "paper", though the CASE tools I am using can use my UML diagrams to begin generating code stubs, sql scripts, etc.
Anyway, my big dilemma is that I really want to do this right. (I architected our website in ASP.NET slowly and all before beginning coding and time and again I am rewarded by the fact that it is very robust and scalable. I can make even major changes with very little chance of breaking the site. So I am sold on proper architecting before ever starting to code). I am proceeding slowly (it's sort of a side project that I can work on anytime) and my team consists of just me.
I am looking for some good software architecture books. I got "Software Architecture in Practice" but I really don't like it. Ironically, the book that has helped me the most was Sam's UML book, with the an example of GRAPPLE (RAD3) in practice.
But given the complexity of this project (distributed components, offline db's and synching issues, etc), I want to make sure I use the best process so that something doesn't end up coming back to bite me.
Any recomendations? I just want a good model to follow, especially that really can only be termed an enterprise app. Case studies maybe. But something READABLE and applicable.
Use version control. I highly recommend Subversion, it is far superior to CVS.
Unit Tests! Write your tests first, then code until your code passes the tests. It'll save you worlds of trouble.
Use adapters -- if you've got a bit of code that processes things in the same sort of way, but can do it to many different kinds of objects, write adapters that adapt each kind of object to the same interface instead of doing tangled logic checks.
MVC, MVC, MVC.
You'll likely need to google or ask followup questions for each of those, but they're good starting places.
Posts: 15770 | Registered: Dec 2001
| IP: Logged |
posted
I live by MVC patterns. Expecially with this project, I will need to use that so that there is no repeated coding/logic and it is (necessarily) loosly coupled.
I've mainly learned through books and just doing, so I'm not really well versed on architecting terminlogy.
Unit Testing: By this, you mean testing both the invidual components and then the larger components these make up, right? So you are saying write the unit tests (decide what the results should be for different criteria- part of the requirements doc, right?) first and then code to that? That makes sense and I try to do that.
I'm not up on XP and have never used NUnit, so I'm not really versed in using a library to do this.
Version Control: What do you mean by this? The way you use this (and CVS) sounds like it is some sort of software.
I am the only person doing this stuff in this company. Consequently, if I need to make a change, either to correct a bug or add some functionality, I usually don't think of using numerically schemed version numbers.
I will check that site out. You said DON'T DO THIS? So it is things to avoid.
So far, I have detailed DB schema diagrams as well as some sample complex data modeled using that schema to make sure the DB scheme models things properly. I also have all the specs and high level requirements for each of the 6 apps. I have also started writing use-cases, though this is very tedious.
The fact is, I am anxious to begin distilling the specs/requirements for common business/db components (and proceed to designing those components from there). But I am afraid that that is jumping the gun.
I am looking for a process to follow. Most stuff I've found seems to assume you know what everything means (throwing around things like "artifact") and is very "skeletal".
posted
Version control is a definite requirement for any major project. It involves keeping track of all the changes in the project, being able to roll them back as needed, and lots of other things. While versioning control is more essential to projects with multiple people, version control with a single person project is very useful as well.
Version control takes care of incremental backups by its very nature, for instance, and removes pretty much all the bookkeeping involved, particularly as every single file is versioned.
Using a unit testing library makes creating and running unit tests very easy. Also, be very, very systematic about it. Every "component" so to speak (and every object, et cetera) should have a "complete" suite of unit tests that run it through its paces in projected problem cases and a few "normal" cases, automatically sanity/correctness checking each output.
There isn't exactly a formalized enterprise development process. Different companies have their own, but they vary greatly.
Some wisdom I've distilled: if you (as you should, and seem to be doing) use components and interfaces all over the place focus on working rather than beauty (beyond basic coding guidelines) or efficiency. Premature optimization is the root of all evil. You can always optimize (after you've profiled)/recode later.
Tackle one project at a time. Divide your project up into smaller ones which build on each other/are independent. Then start with the root dependencies and work "up"ward. Once each sub-project passes all unit tests, stop working on it and work on the next sub-project, and don't backtrack until done/a unit test up the road breaks due to older code.
Use libraries, use libraries, use libraries. You should research possible libraries for pretty much everything. You'll be surprised at what you can find. However, you don't want to use libraries that are suspect.
Posts: 15770 | Registered: Dec 2001
| IP: Logged |
posted
Thanks. That is some good advice. I try to follow most of those principles already.
I guess the real difficulty is self-discipline. As my spec/requirements gathering and DB schema design near the end, I have a real desire to jump in and start building common components (like the DB comm module which, aside from general DB communication, will also tackle issues regarding synching of offline DB's that our techs will carry in their laptops when they are out in the field. But even that is tentative design, since it seems probably that I'll want to make that a separate module, since not all apps will need that functionality.)
I'll look into automated versioning. I can see it's power. It's so easy when your just one person to fix a bug or make a slight change with no procedural steps. Not good, I know.
OO is second nature. That's all I really ever learned, so 'componentizing' common functionality is the only way I try to go. And I do like to use reliable 3rd party libraries, especially when it comes to ASP.NET server objects (like date pickers, etc). It's hard to find exactly what you need, though, when your talking about business object logic components.
Are there any processes you recommend?
Thanks. Oh, and did you send me an email earlier? I get a lot of junk mail (spam filters are touchy about what they eat) and I may have inadvertantly deleted it.
posted
I downloaded Subversion (TortoiseSVN) as a Windows Explorer enhancement. Looks easy to use for versioning. Now to see if it is workable with VS.NET.
Printer-friendly view of this topic
