views:

89

answers:

2

Hi,

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?

+6  A: 

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!

marc_s
thanks Marc - in terms of using separate assemblies to force the separation, I guess this is based on the concept that in the UI layer you can add the Business Logic layer project as a reference, but you should NOT add the UI layer as a reference in the Business Logic layer project? Is this correct? This would be what forces the issue? And then in you're would it be the case you should not let the UI layer have as a reference the data access layer? (i.e. force it to go through the business logic layer)
Greg
@Greg: exactly - your UI layer references the Business layer, which in turn references the Data Access layer - but not the other way around. You got that absolutely right! And typically, one doesn't want to have the UI layer talk directly to the data layer either - the layer should be neatly stacked on top of one another.
marc_s
+1  A: 

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.

chibacity
thanks - I guess maybe I should have used a phased release approach potentially than Prototype - in my mind the app would start getting used by 1 or 2 people in the first stage, but then have to evolve before further rollout
Greg
Hi Greg. If you have the opportunity to work with a small group of users initially that can prove to be a huge asset if they represent some sort of balanced view of the wider audience. Work with them to get requirements and iron general wrinkles out - feedback is always valuable. A lot of developers never get to work with users! :)
chibacity