C# – the difference between a prototype and a production level solution

asp.netcnetvisual studio

This question is purely for learning and to step-up my technical understanding. I know there is no perfect solution and this question has possible never ending solution list but I think it's very important for every architect to understand the difference between demo and a live project.

I created many demo solutions in .Net in the past. I now have been assigned to architect and implement a production level web solution so I wanted to ask – on a very high level, what is required to convert a demo into a production level solution. From my understanding, this will require (other than functionally implementing clients' requirements):

Unit testing every method
Ensuring ~100% code coverage is achieved
Logging all exceptions and possible pointcuts – possible with AOP
Using interface design pattern, dependency injection, possibly by
using a framework e.g. spring.net
Using performance counters and
profilers for instrumentation
Applying appropriate security – i.e.
windows authentication (if that's whats required by client).
Transaction management on every single method
Back up of the web application files before new deployment of solution

What else?

My question is more related to technical side instead of functional/documentation because otherwise we will go into another path 🙂

Thank you.

Best Answer

I think the most important difference is that a prototype's objective is:
1. To prove that a problem can be solved in a certain way OR
2. Give client / management a feel of what the product would look and feel like

whereas the objective of a live system is:
1. To solve a certain problem / address an issue.

Notice that the objectives of the two are completely different.
Therefore, in my opinion a prototype should be thrown away before developing a live system.

This is also because a prototype is usually a 'quick and dirty' project, thrown together without any of the considerations you've rightly pointed in your question (like testing, performance, security and a lot more).
So you'd be better off starting a new, proper project, than trying to make a bad project better.

Related Solutions

MVC vs MVVM – Difference Between Controller and ViewModel

The controller and the ViewModel differ in various ways.

In MVC the Controller knows the view, it can change the View. It also knows the Model and can call it. In MVVM a ViewModel is an abstract representation of the View and does not know the concrete UI, it wraps the Model in a way so that it can be displayed as desired.

In classical MVC, a controller is just a strategy of the View to interact with the Model. In fact, sometimes a Controller isn't even necessary. In MVVM you don't need it, as you can have different ViewModels for the same View if you need different behaviours. In MVC you could have for example a ReadOnlyController or an AdminController to communicate with the Model. In MVVM you could just have two ViewModels and you choose the one you need for the View.

But they do have some similarities. In both patterns, the View is an observer. In classical MVC, the view is an observer of the model, in MVVM it's an observer of the ViewModel.

Both patterns are meant to provide a separation of concerns. MVVM primarily aims to provide an abstraction of the View, completely independent of the UI technology in use. MVC does not go that far. It's primary focus is on separation of concerns, so that you don't put business logic (the Model) into the view.

You might also find this answer of mine to a similar question helpful.

At last, I should say that both patterns belong to the same family. MVP, of which MVVM is a descendant is a sibling of MVC. If you want to know more follow this link to Martin Fowler's website, he explains everyting in detail.

C# – Difference Between Method Header and Method Signature

According to the C# spec, a method header consists of:

attributes_opt method-modifiers_opt return-type member-name (formal-parameter-list_opt)

So to extend what you've shown:

[OperationContract]
public void SumNumbers(int firstNumber, int secondNumber)

Above example contains examples of the possible parts that make up a method header, while the minimum (all non-optional parts) would be something like:

void Foo()

As for the signature, see 3.6 Signatures and overloading:

The signature of a method consists of the name of the method and the type and kind (value, reference, or output) of each of its formal parameters, considered in the order left to right. The signature of a method specifically does not include the return type, nor does it include the params modifier that may be specified for the right-most parameter.

The following example shows a set of overloaded method declarations along with their signatures.
interface ITest
{
   void F();                  // F()
   void F(int x);             // F(int)
   void F(ref int x);         // F(ref int)
   void F(int x, int y);      // F(int, int)
   int F(string s);           // F(string)
   int F(int x);              // F(int)         error, F(int) already exists
   void F(string[] a);        // F(string[])
   void F(params string[] a); // F(string[])      error, F(string[]) already exists
}

So the signature of your second example would be:

SumNumbers(int, int)

See also Method Signature in C# on SO, especially Eric Lippert's answer.

Best Answer

Related Solutions

MVC vs MVVM – Difference Between Controller and ViewModel

C# – Difference Between Method Header and Method Signature

Related Topic