-1

Sorry in advance for the wall of text!

Scenario:

We're looking at what technology to choose for a LOB app that needs to support a "stand-alone" model (frontend + backend running on desktop machine), but also local server mode (backend installed on a local server), as well as Software as a Service via the internet (backend installed on a hosted server).

We want to minimize the development work, which is why we chose the Silverlight frontend. We intend to re-use the same codebase for all 3 models.

The LOB app is heavy on data inputs and will do some math work on the backend. We will have a large amount of views. And we will have a database with 80+ tables. We currently have our own DAL that enables us to use MSSQL, MySQL and Oracle as DBMS's.

The current vision is to use an Agile TDD Silverlight 4.0 MVVM app as frontend in C# with the Caliburn framework. And to have a WCF (RIA?) service as backend (Non Silverlight, plain .NET 4.0). This fits the different models well, since it's just a matter of where the backend is installed. For the SAAS model, we have a server on the internet where the backend could reside.

Questions:

  1. Does this sound viable at all, or is it whishfull thinking that we could have the same codebase for the different models?

  2. With regards to the backend, we are looking into WCF RIA Services, but would like to have "Message Security", which does not seem to be possible in the Silverlight implementation of WCF. Is WCF RIA a valid choice? Or is plain WCF "better" with regards to security in any way?

  3. With regards to the different DBMS's we need to support. Is this viable to do with WCF RIA Services? Or are we better off creating our own BLL/DAL and expose that ourselves via plain WCF?

  4. Does anyone have experience with a multiple DBMS setup using no inline SQL, just Stored Procedures? The original app is heavy on inline SQL, but we are wondering how maintainable this app would be with only Stored Procedures in the different DBMS's.

  5. Final question, with regards to MVVM and security, we would like to "hide" as much of our logic in the backend for security/code protection reasons. What would be a logic thing to do for this? We need to do TDD, so we need to be able to mock-out the Model, which means it needs to be available in the frontend. But we need all the logic to be in the backend. Should we just use a "wrapper" in the frontend that "links" the "real model" in the backend? Kind of a dummy model that fits 1-on-1 with the backend model. Or is there a "better" way to do this?

Thanks in advance for any help you can give us in any of these subjects!

Huron.

Huron
  • 1,055
  • 1
  • 9
  • 16
  • Not used the latest version but recommend you have a look at Rockford Lhotka's CSLA framework. – Rikalous Mar 22 '11 at 10:48
  • I actually did look at CSLA Rikalous, but I was never "convinced" that it was something we could/should use. Perhaps I should revisit that now that you mention it here again. Will put that on my todo list :) – Huron Mar 22 '11 at 12:53

2 Answers2

1

  1. It should be viable, but you're gonna have to really think the communication model through. The SaaS scenario is the most restrictive and security sensitive, so you should start from there and scale back to the all-local setup.

  2. I'd advise against RIA services. As often is the case with MS it's nice for simple stuff, but you'll soon enough run into it's restrictions and then curse it. See here for how to do Message Security in SL.

  3. As in Question 2: I wouldn't go with RIA, but even if you do, you can use Entity Framework and keep it DBMS agnostic.

  4. I for one am a fan of stored procedures. Yes, it creates multiple points of deployment (and the inherent risk of version differences), but I always say "keep SQL in SQL".

  5. Unfortunately what you're describing is a common issue in TDD of interfacing systems. I'd use a mockup client to test the server and then use the real server to test the client.

Vincent Vancalbergh
  • 3,267
  • 2
  • 22
  • 25
  • Thanks for your answer Vincent. With regards to number 5. I think I described it wrong, I meant to ask, with an eye on security and code safety, I want to get rid of as much logic as I can in the frontend. But that would mean my model in the frontend would be a dumb "copy" of the model in the backend, in other words adding another layer, that's "not necessary", but only is there for the separation of concerns. It sounds kinda okay in my head, but I'd like an opinion on that. Rest of your answers are clear and are inline with our toughts. Thanks! – Huron Mar 22 '11 at 12:47
0

Here is what we've ended up choosing for our LOB - local/client-server/saas app :

  1. This turned out to be extremely viable. We have very few exceptions, most of the codebase is exactly the same, for local, client server and saas.

  2. We decided not to go with WCF RIA, but to use regular WCF Calls, we are using "TransportWithMessageCredential" to secure the communication.

  3. We are using Entity Framework for exposing the database to our backend application. There we have our domain layer and our custom "Entity" classes, which we fill based on the EntityFramework Classes we get.

  4. Since we are using Entity Framework, our SQL statements are all completely gone. We are using Linq to select what we want. So far this is working great. So no more inline SQL. And by introducing separate layers (Entity Framework -> Context class -> Mapper Class -> Entity Class) we have a high maintainability.

  5. We have dumbed-down the frontend as much as possible. The ViewModels we have there are strictly used for filling all the bound-properties so the View has data to work with. All the decissions with regards to what data or what is possible are being done in the backend. The entire flow of the application is run by a Manager class in the backend which uses a WCF Duplex connection to tell the frontend what to do.

Huron
  • 1,055
  • 1
  • 9
  • 16