Clever Geek Handbook

Creation of an extensive project for sale

I am about to start a C # project from scratch which will be made up of multiple modules so that 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 the web - an application that the user can use to create all the material.

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

  • What classes should I make available to be overridden by the client so that I can provide extensibility in our modules?
  • Which "package" should you use to "sell"? DLL, CAB, MSI?
  • Do I have to use SubSonic / NHibernate so the user can create their own DAL? Our prototype implementation will only use Oracle.

I am now lost right now, I know what to do but not how I can do it (meaning this ideal coding path).

Any good programming ideas are gladly appreciated :)

+1


source to share


6 answers


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

For integration, learn about inversion of governance principles and how it is used for extension purposes. Watch out for MEF, Microsoft Extensibility Framework. As for what, your integration points will depend largely on the type of application you are writing and your target audience. It also depends on what kind of control you want to give to third parties. For example, a reflector has a large, almost wide open plugin structure.



DLL and CAB are libraries and storage formats respectively. They don't do much on their own. MSI is a form of installation and can contain DLLs that will compose your application. Regardless of the type of installation you have, the easier it is to use it, the more people who will try your product.

The data layer itself does not necessarily matter. People probably won't create their own data layers for your application, and if they do, they should be able to use what they want if your extensibility framework gets the job done. More importantly, no matter which DAL you decide, you need to check if it can work across different databases, if that's important to you and how much work is required. You also need to ensure that the functionality you use in the DAL works for all the databases you want to support. NHibernate has a few features that don't work in all databases it runs on.

+3


source


you will rewrite any application at least once in your lifecycle. get something to set a value and then worry about how good your code is.



you can spend a year building a totally coded app that nobody wants to use, or you can spend a couple of months and the rest of the year either improve it or work on something else if it falls on his face.

+2


source


First of all, think about HOW it can be extended. If you just provide full extensibility, you run the risk of insecurity and instability. You can allow classes to be overridden, just make sure you only mark the correct methods as "virtual". The type of package for sale depends on your target audience. If you are targeting power users, the DLL should be OK. But if you want an easy-to-use system then MSI or any other installer will be wiser.

When it comes to DALs, you really need to analyze the advantages and disadvantages of each and choose the one that fits.

Make sure you make it extensible, but you can expect feedback to indicate how much of it will go public.

+1


source


I think I'm going to buy this book , it touches on my problems in "how to do it" and from Brad Abrams perspective, not bad :)

+1


source


Do what works first and then get feedback from potential customers.

0


source


I don't think you are taking the right approach. You don't have to design software in terms of "selling". You develop software to do the work required by your business model and its rules. So, in terms of "selling", I would say that I worry about having a good product first, software (no matter how good or how badly written) will be second, and you will be rich as long as the software does. your job and your product is a hit.

Have you ever heard of how ebay got started? They were very successful for a long time, but had very bad C ++ code (and who knows what else).

0


source






More articles:


All Articles