views:

168

answers:

6

Howdy,

I am going to start a C# project from scratch that will consist of several modules so it can be sold by modules of an existing PHP/ASP/MySQL/Oracle/MS SQL application that manages to show 3D objects and create 2D and 3D CAD files from a web app that the user can use to create all the stuff.

My question is, to start from ground zero, and having the "sell" point of view, it should be a good programming method that I should implement, design patterns, unit testing, etc... how will I know how to apply them, and is there any good tutorial / "show me the way" kind'a thing to know about these things, like...

  • what classes should I make available to be overridden by the client so I can provide extensibility in our modules?
  • what kind of "package" should I use to "sell"? DLL, CAB, MSI?
  • should I use SubSonic / NHibernate so the user can generate their own DAL? Our prototype implementation will use only Oracle.

I'm kinda lost right now, I know what to do, but not how I can accomplish it (having this perfect coding path in mind).

Any good programming ideas are gladly appreciated :)

A: 

First make something that works, then get feedback from potential customers.

divideandconquer.se
How about finding out what potential customers want first?
Jeff Yates
that I know :) they want to use the current project and have the advantage to extend it and use our ideas in their project, specially the 2d/3d cad auto generated sketches.
balexandre
+3  A: 

For a quick hit of each of your explicit questions I would say.

As for the how of integration, learn inversion of control principals and how it is used for extensibility purposes. Keep an eye on MEF, Microsoft Extensibility Framework. As for the what, your integration points will depend mostly on the type of application you are writing and your target audience. It also depends on how much control you want to give third parties. Reflector for example has a great, almost wide open plugin structure in place.

DLL's and CABs are libraries and storage formats respectively. By themselves, they don't do much. MSI's are one form of installer and can contain the DLLs that will make up your application. Regardless of the type of installer you have, the easier it is to use, the more people that will try your product.

The data layer itself doesn't necessarily matter so much. People probably won't be creating their own data layers for your application and if they do, they should be able to use what ever they want if your extensibility framework is doing its job. More importantly is that whatever DAL you do decide on, you need to check to see if it is capable of running on different databases if that is important to you and how much work it takes. You also need to make sure the features you use in the DAL work for all of the databases you want to support. NHibernate has several features that don't work in all of the databases it runs on.

Chuck
+1  A: 

First of all, think just HOW extensible it should be. If you just provide full extensibility you risk lack of safety and instability. You can allow overriding classes, just make sure you only mark the right methods as "virtual". The type of package to sell depends on your target audience. If you're targeting power users, then DLLs should be "OK". But if you want an easy to use system, then a MSI or any other installer would be wiser.

As for DAL, you really should analyze the advantages and disadvantages of each and choose one that fits.

Make sure you make it extensible, but you may want to wait for feedback to specify what part of it becomes public.

luiscubal
+2  A: 

you'll rewrite any application at least once in its lifecycle. get something out to establish value then worry about how pretty your code is.

you can spend a year making the perfectly coded application that nobody wants to use, or you can spend a couple months and the rest of the year either improving it, or working on something else if it falls on its face.

Kyle West
I do pretty much that now, but don't you think that we should code right from the start, or do things ok and then refractoring and applying design practices is more advantageous?
balexandre
i think as quickly as you can get a well tested and production ready product out the door you should.
Kyle West
A: 

I don't think you're taking the right approach. You shouldn't design software from the "sell" point of view. You design software to do the job required by your business model and its rules. So, from the "sell" point of view, I'd say worry about having a good product first, the software (doesn't matter how good or how poorly written it is) will come second and you will be rich, as long as the software gets the job done and your product is a hit.

Ever heard about how ebay started? For a long time they were very successful, yet had really bad C++ code (and who knows what else).

Ricardo Villamil
+1  A: 

I think that I'm going to buy this book, it addresses my concerns in "how to accomplishing it" and from Brad Abrams perspective, is quite good :)

balexandre