Application architecture for client to WCF service

0
votes

I'm curious about the correct way to architect an application that consists of the following (that needs refactoring):

Excel Addin COM-Visible client library that includes WinForms and Methods exposed to Excel (calculation calls and form activation methods) This then uses functionality in the client library to connect to the WCF services. WCF services currently contain calculation logic, validation logic, database access via ORM tool.

i.e. Addin -> Winform/Direct call in client DLL -> WCF -> DB or calculation

Currently this exists in just 2 projects. My first though would be to re-architect as follows:

Client Side Projects

  • Excel "View" (Project.Client.Excel), this limits the level of COM visibility to one project.
  • WinForm "view" (Project.Client.UI)
  • Presentation for both sets of "views" (Project.Client.Presenter)

Server Side Projects

  • WCF "view" including data transfer objects? (Project.Server.WCF or Service)
  • Server side presenter (Project.Server.Presenter)?
  • Business Logic (Project.Business)
  • Data Access Layer (Project.DAL)

My questions are:

  1. Where should the DTOs sit, in the WCF project or as their own library/project?
  2. Where do the entity conversion routines belong (Data entity <> Business Entity <> DTO)? All in the business logic layer or some there and some in a server presenter?
  3. What should the correct architecture be for this type of scheme?
  4. Plenty else I've probably missed?

Part of the idea for the refactoring is to correct the architecture, separate concerns etc, and enable the inclusion of unit tests into the design.

2
c#wcfarchitecturen-tier-architecture
Please add type for every project (Class Library, WPF etc) and role that Presenter performs in your solution. - Dmitry Harnitski
Currently everything ends up a DLL as the Excel addin is the true front end due to how the users work. WinForms are used as they are considerably richer and more functional than jamming everything into UserForms. The intention is for everything to remain as DLL class libraries but be split better across projects architecturally. As part of the work I want to split out the code-behind of the WinForms to use MVP so that unit tests can be added. As such I envisage the presenter working both for the forms MVP and effectively as a passed-through call from the Excel library. - anonymouse
i.e. <ExcelLib>.DataService.GetTimeSeriesByID(...) passes through to <PresenterLib>.TimeSeries.GetById(...) so as to use common code for both forms (view/update/etc) and excel function calls. The Excel library will then just be wrapping the DTOs for COM access. Does this make it clearer? I'm going to use MVP and WinForms for this as WPF and MVVM doesn't work as well (in my reading) when you wish to put an ASP.NET front end on (rather than Silverlight which is a non-starter), which may be a requirement for some parts at some stage. - anonymouse

2 Answers

0
votes

This is how I would structure that but there is no 100% correct answer to this question. Many variations will make sense until they make your work comfortable.

  • Excel "View" (Project.Client.Excel), this limits the level of COM visibility to one project.
  • WinForm "view" (Project.Client.UI)
  • Presentation for both sets of "views" (Project.Presenter)
  • WCF Host (Project.Service) - Web Site with *.svc files if you host in IIS (no contracts here). No much business code here it is only for hosting methods implemented in BLL.
  • Business Logic (Project.Business)
  • Data Access Layer (Project.DAL)
  • Contracts (Project.Contract) - Operation and Data Contracts. This is library used by both WCF client, server and BLL.
  • Shared (Project.Shared) - common helpers to better structure dependencies.

Where should the DTOs sit, in the WCF project or as their own library/project?

Contracts

Where do the entity conversion routines belong (Data entity <> Business Entity <> DTO)? All in the business logic layer or some there and some in a server presenter?

Business for middle/small size project.

What should the correct architecture be for this type of scheme?

Your seems to be fine.

Server side presenter (Project.Server.Presenter) - this makes no sense for me because there is no GUI that consumes it

0
votes

Where should the DTOs sit, in the WCF project or as their own library/project?

You don't want them in the WCF project as this means the client would have to reference that server-side project. Better to keep DTOs, WCF service contracts (interfaces), etc., in a separate "common" project that both the server and client projects can reference.

Where do the entity conversion routines belong?

Data entity <-> Business entity in the data access layer; Business entity <-> DTO in the business logic. Of course, it's also perfectly acceptable to use your data entities across all layers, avoiding the need for all these different entities and mapping code that you will need to keep updated. I guess it depends on the complexity of your system, but take a look at EF4 POCO.

As for your other questions, without knowing a lot more about your requirements and design, you look to be on the right lines with your list of projects.