views:

54

answers:

3

I'm writing a tool in C#.Net that will be used to generate Catalogs of content which users can browse. Initially I am creating a WinForms based interface, but in the future I'd like to be able to create a web based interface as well. So I've been careful to generalize the interface to a Catalog so that it does not depend on a specific UI.

My only experience with web development has been creating my own HTML website back in the early 90's, and I've done a little ASP (not ASP.NET). Now with ASP.NET it seems that I should be able to leverage my existing C#.Net object model, to create a web base interface. But I really hasn't done anything with ASP.NET beyond a simple hello world example.

Are there any special considerations I should make in designing my object model so that later I can create a web interface to it?

+2  A: 

There really shouldn't be that big a difference.

Be careful about placing too much “intelligence” in your entity classes. That’s a pattern I’ve seen often in Windows apps. Don't make references to controls that are specific to Windows Forms development in the parts of your project that you want to reuse for the web application.

Repository patterns work well with both Windows and Web applications, because you often want to optimize the web apps differently for performance with multiple users.

Jakob Gade
+1 for being careful about intelligence. I would +1 again if I could for optimizing them differently.
tster
Thanks for the answer. I looked into it, and I looks like I am using the Repository pattern even though I didn't know that's what it was called.
Eric Anastas
+2  A: 

Here are few things to follow:

  1. You should package your object model is separate project (that you need to do anyway to share it among different projects) and make sure that you do not add specific references to it (for example, don't add System.Web, WinForms, WPF etc) - this will automatically avoid any unwanted dependencies.
  2. Try to have your classes as lean as possible. Avoid classes that track change states etc - in web scenario, tracking state over multiple requests is expensive. So it's best to have to your objects carry data only.
  3. Consider the possibility that your objects may need to be serialized and/or passed over a wire. For example, a middle ware services serving both windows & web client. Or web page storing the object in the view-state.
VinayC
Regarding number 1. I have developed a set of abstract classes and interfaces that define how a Catalog should work. I then later may create multiple implementations of a Catalog that have different storage mechanisms. Should I also break these different implementations into a separate project from the abstract definitions?
Eric Anastas
I am from that school of thought who believes using entity object as plain data transfer object. So I would avoid putting concerns such as persistence into a same entity - instead, I will choose different class/layer. Simple example could be a Catalog being plain class having properties and CatalogManager would manage persistence. In word of O/R mappers, I may not even have to write this class (see Entity Fx). In your case, you have to move your implementation in different assembly - otherwise, in N tiers case, UI tier would have ref to your assembly that has persistence implementation.
VinayC
A: 

Your requirement can be handled with a multi-tier architecture:

http://en.wikipedia.org/wiki/Multitier_architecture

Christopher Hunt
-1. A buzzword isn't a good recommendation really.
tster
I really think that 'N-Tier' is quite descriptive. I'll change it to multi-tier though.
Christopher Hunt