in .net, what programming model would be good for prototyping, but then reusable for production (for business logic/data access layers)

Question

In .NET land what would be a good approach for quick prototyping of a concept (i.e. development just on my PC) that could then be extended out to product (users across LAN/WAN), BUT in a fashion that the model/business logic code and data access layer code can be used as is?

One thought for example I had as to do: (a) WinForms with business logic and Entity Framework layer to SQL Server Express on my PC, then (b) Go then to ASP.net (using the business logic / data library) with SQL Server/IIS

Any comments? Other suggestions?

Answer 1

I would recommend trying a layered approach:

• put your entity data model and validation classes into a separate assembly
• put additional business logic into a separate business logic assembly
• put your services (WCF or WCF Data Services) into their own assembly

All those base layers are pretty much independent of what you choose as the UI frontend technology. You can make choices here (e.g. Linq-to-SQL vs. Entity Framework for your data access; do you need a WCF-based service layer, or does your app use direct DB access?) more or less independent of what you put on top of that for the UI layer.

And on top of those base assemblies:

• create your UI either as Winforms app, or as an ASP.NET (Webforms or MVC) web app (or both)

If you have layers and if you architect them well, you can reuse a large portion of your code and business rules.

Try to put only stuff that's specific for each UI technology (Winforms vs. ASP.NET) into those frontend presentation assemblies. Keep all the common business rules, validation rules, access and service layers separate.

And again: it seems you believe that "going ASP.NET" excludes using WCF/WCF Data Services - not at all ! You can easily use data from a WCF service in an ASP.NET app. You're not losing anything by layering your business and services layers - those can be easily reused in both Winforms and ASP.NET apps!

Answer 2

A few comments:

Prototyping as an approach to developing production quality software can be problematic, as the very nature of prototyping can mean that the software and design quality are not that great. Prototypes are not meant to be great quality by definition.

If the goals are to get some feedback from the intended customer\user during the early stages, it can often be a good idea to not prototype full vertical slices (e.g. UI -> Business -> DB), but work with UI mockups which can be used to explore ideas with users. The mockup is flexible and easy to change, but is not fully functional e.g. does not have business logic or persistence. This approach allows users to get some idea of functionality and be involved in the design and requirements gathering process. It will be quick to change the mocks as requirements change, especially as there is no business logic or database code that has to be changed with it. An example of a UI mocking tool is Balsamiq:

http://www.balsamiq.com/

If one of the overall goals of prototyping is to investigate and explore different technology choices, these can be done in isolation of UI mockups, and in a more abstract fashion i.e. pure technology investigation rather than geared at delivering the exact needs of a prototype which can be changing massively. The UI mockups may change a lot via user feedback, so having technology investigation as a different activity can make this process simpler i.e. there is less coupling as things will change a lot during the early discovery phase, and having to change the "backend" constantly because UI ideas are developing so rapidly, will slow you down.

In terms of speeding up the pace of software development, leverage third party libraries. If you are using a database for persistence, look at ORM solutions which could massively reduce the work needed to develop a data access layer e.g. nHibernate. Depending on what UI technology you use, look at third party control libraries.

In the industry, the approach that has very much replaced prototype driven development over the years is: Agile. It seeks to tackle the changing needs of users head-on by always striving to deliver features, but has a focus on developing high quality software through techniques such as TDD.