How to decide the right design pattern for a .NET client app that will eventually share code with a web app?

Question

I am new to design patterns, but I have been trying hard to implement some in the last year. I started at a new organization, and all the code was contained in the form. Since I got here, I've been trying to use an MVC approach for our .NET 2.0 application.

Other developers have started to see the need for this approach, and we are reaching a point where we want to agree upon a design pattern that we will all follow. And while I have been trying to learn, I'm not sure I know which pattern is the best to implement. Here are some of our design constraints:

1. Client application with local data stored in an Access Database that is synced to an Oracle Database (need to support disconnected users)
2. Client application functionality will be also available to the web in the coming year
3. .NET 2.0 environment that will be moving to 3.5 or 4.o in the next year

Please let me know if you have other questions. I appreciate your help.

Thanks!

Answer 1

This is a prime example for what a service layer is used for:

(Article with more indepth descriptions of the various layers)

You can stick with your MVC architecture, but now the controller calls upon your service layer (a seperate class library project in your solution), for any business logic methods. It sits on top of the domain and repository and allows you to perform business related actions between any project using the service layer.

This way your business rules aren't spread all over in your controller and your controller is left to do its job: retrieve and organize data to be passed into the view.

In this way, you can have your client application and your web application both reference the same service layer project and share the business logic code between them.