0

I've recently inherited a project which is a rich Winforms application written in C#. The existing architecture, based around the CSLA framework, is not very clean with data access inside the domain models and too much logic in the data layer (stored procedures) resulting in maintenance and performance problems.

The current options on the table are to either try and fix up or replace the domain layer and data access. I also need to be looking forward towards a Web UI.

(CSLA provides a simple way to turn on a middle tier through configuration, enabling a WCF service)

My prefered plan for Web UI is for a single page app with a Web API in the middle tier.

My question is, what is my best choice for architecure/frameworking this? I want to reduce the entry point for developers working within this framework.

I am thinking of these options:

  1. Fix up CSLA and transition over to new domain object whilst extracting the data access into a repository pattern. Eventually write a Web API layer with view-models mapping from the domain objects.

    • This means the dev team will need to be trusted with implementing CSLA layer correctly (unless I can template objects)
    • This does mean that I am free to replace my data access as I please
    • Using CSLA means it is compatible with current Winforms app (which I can tidy with the MVP pattern)

  2. Move to Entity Framework Code First as the domain layer, which also takes care of my data access

    • I have tiny bit of EF experience and have always found the Code First to have high entry point of knowledge
    • This means my data layer is tied into EF
    • Would need to create my own WCF service for existing Winforms

  3. Use a simple data access layer with something like Dapper and a repository pattern, and replace the domain layer with something entirely new that will support both Web API and Winforms (even if small amount of adaption required)

    • What are the current prefered frameworks for the domain layer (other than CSLA or Spring.Net which appears to be very quiet) for this?
oatsoda
  • 2,088
  • 2
  • 26
  • 49

2 Answers2

1

To some degree I think the answer depends on how old your version of CSLA is at this point.

If you are using version 3.8, 4, or 4.5 it is probably well worth just separating out the data access code using the techniques described in the 'Using CSLA 4' ebook. The reason this would be to your benefit is that (having done that) your same business code will translate to WinRT, Android, iOS, Linux, OS X, as well as to all .NET platforms with little or no change.

If you are using an older version of CSLA (1.x through 3.0) the amount of work required to get your classes up to modern standards can be quite high. It still might be worth it in order to get the cross-platform business logic capabilities provided by current CSLA, but that's a business decision you need to make.

Rockford Lhotka
  • 842
  • 6
  • 9
  • We're version 4.0.1 - no direct upgrade at the moment due to overridden `Save()` methods. After more digging I have come to the conclusion that the problem is that the domain objects have been mapped directly from the data schema and don't use much of the CSLA framework such as Parent-Child, Child Properties etc. So a gradual effort to re-model each of these is probably (hopefully!) the way to go. – oatsoda Apr 14 '14 at 07:13
  • Is a WebAPI on the roadmap for CSLA? – oatsoda Apr 14 '14 at 07:13
0

I think you will want to get away from CSLA as quickly as possible. Its major issue is coupling: the domain objects are incredibly complicated and have base class dependencies. While CSLA was an effort with good intentions, that approach is no longer considered best practice.

WCF is likewise a nightmare to use in my experience: complicated to configure especially with respect to security.

If feasible, I might try to abstract your business logic into RESTful services using the WebAPI framework. Use a library like RestSharp to send HTTP requests when a form loads or the user presses a button. You will then be able to easily migrate to a modern browser-based implementation in the future with something like Backbone.js.

Dislaimer: I've never tried this approach. WinForms is quite obsolete at this point and wasn't designed to work against HTTP services. It's possible you may just have to start over from scratch.

Since the time of CSLA, there has been a general awareness that "frameworks" for DDD are unnecessary. Wherever possible, inheritance is to be avoided and POCOs are to be used instead. This will also make testing much easier because classes have many fewer dependencies.

Community
  • 1
  • 1
Josh Kodroff
  • 27,301
  • 27
  • 95
  • 148
  • 1
    "WinForms is quite obsolete"; "general awareness that 'frameworks' for DDD are unnecessary"; Do you have any sources to back these statements up? – oatsoda Mar 28 '14 at 09:29
  • 1
    That WinForms is an obsolete technology? It was replaced by WPF in 2006 and WPF has since been replaced by WinRT. As for DDD frameworks, I recommend you check out the more well-known figures in the community: Eric Evans, Vaughn Vernon, Udi Dahan, Greg Young. To my knowledge, none of them advocate frameworks like CSLA, as well as my own experience in doing DDD for a couple of years now. – Josh Kodroff Mar 28 '14 at 20:46
  • 2
    To be exact - WinRT didn't replaced WPF but rather provided yet another flavor of XAML-based GUI. I would't say WPF or desktop are going away - we can rather see a more distinct split into consumer-targeted and producer-targeted GUI-s. But WinForms is obsolete anyway. – Bartłomiej Szypelow Mar 31 '14 at 11:32
  • WinForms may have been superseded, but I would not say obsolete. In my experience companies are reluctant to risk cross-training to WPF, especially with Web/Mobile offerings to consider as well. Is Entity "Framework" not considered a DDD framework then?! – oatsoda Mar 31 '14 at 14:42
  • Entity Framework is a object-relational mapper. You *can* do DDD stuff with it, but you're going to want to be careful to avoid coupling your domain logic with your data persistence. If you have very well-defined schema that is easily changeable, then this is less of a worry. If you have to work with legacy code, then you definitely want to make sure that your data persistence is decoupled from your domain logic because you don't want a nice, clean domain model to be tied down to a bad schema. – Josh Kodroff Mar 31 '14 at 15:08
  • Yes, that is pretty much my thoughts about EF - just good to have others opinions to help confirm them. – oatsoda Apr 14 '14 at 07:09