Can I avoid duplicating my business layer? (.NET)

Question

I have a tech demo application to write, with multiple clients: web client (ASP MVC 3), desktop client (currently it'll be a WCF app, planning to spice it up to Metro later) and a mobile client (Wp7 is the default task, but if I feel like a time-millionaire, I might try MonoDroid too)

I was thinking using WCF for the clients.
I was thinking using EF Model First for back-end.
However my problem arises when I try to figure out where do I put my domain logic (validation, computed properties, etc) without having to manually duplicate everything I already declared in my EF Model.

My first main problem is that EF has a nice object tracking built in (obj.Components.Add(...); db.Save();), but this functionality isn't available on the clientside easily. Is there a way around it without having to implement my own? (I know how to do that, but that's way too much work for this demo)

My second main problem (as the title suggest) is the domain logic, mainly validations.

• Should I recompile the business objects to clientside and serialize the wcf into the same objects?
• Should I try to work with the WCF generated classes on client-side? (back to the first problem)

• Should I try to use shared assemblies?

• If I write my logic into MVC controllers, my WCF service won't be able to call them neatly.

• If I write a separate BusinessLayer should that also use EF entities or should I write custom Business Objects? (essentially duplicating everything AGAIN)
• If I use EF entities, I have to partial the validation on, which is ugly (at this point, should I just switch to EF Code first?)

• Is there a nice way to use these same validations on client side?

• Should I scrap the whole thing and try RIA services?

Oh, so many questions...

Spiritoso

I'd use plain .net objects as domain, and then add persistence with NHibernate or EF Code First. – Hawfinch

@CodeInChaos: this is what my coworker is suggesting to me too :) – Spiritoso

Answer 1

I've built cross-platform apps before on Windows (specifically WPF / Silverlight clients, C# SQL Server back end) and what I've done is this.

• Employed a messaging layer or middleware (RabbitMQ for asynchronous messaging, or webservices for request/response) and serialization technology (Protobuffers or JSON) that works across all three boundaries. Use a cross platform middleware where possible. This is why I mention RabbitMQ / protobuffers / JSON.
• Moved all business logic to the server - the client cannot access the database at all and has to go through the middleware. Clients, including desktop, literally become like thin browsers accessing middleware services for all operations.
• Created shared assemblies to hold messages, datacontracts and common classes between client(s) and server which can be referenced by all clients and the server.

This last step (shared assemblies) involves creating 1 project which is full C# compatible (so works on WPF Desktop or Server) and additional projects for each web client (Silverlight, WP7). To dual deploy code on multiple clients you have one copy of the source in the desktop assemblie and then "Add as Link" the same source files to Silverlight / WP7 assemblies. You will have to have a few #if preprocessor statements but by and large it is possible to dual deploy large chunks of code using this method.

Your stack becomes

Clients:

all clients have serialization, client side implementations of webservices/middleware and MVVM / MVC patterns

Middleware:

middleware implemetation on server / wpf desktop can be the same. Wp7 and monodroid etc will need to be different

Messages/DataContracts:

shared across all clients/server using the techniques I outlined above

Server:

All business logic, DB access and server-side middleware implementations. For DB Access I've used PetaPoco as an excellent MicroORM. I believe a microORM implementation powers stack overflow but I might be mistaken.

I would also take a look at this article for inspiration. It is possible - I've written client/server apps with SL/WPF clients and C# servers, also WPF client/Java servers using the above methods.

Best regards,

Peroxidase

I'll look into the added benefit of a middleware layer. I'm convinced on the recompiled-dataobjects and JSON serialization and along with EF Code First, I think I'll manage. Thanks – Spiritoso

Wcf is essentially middleware. Either way by abstracting your functionality behind web services, the client remains thin and client tech can be re engineered more easily – Peroxidase

"creating 1 project which is full C# compatible (so works on WPF Desktop or Server) and additional projects for each web client (Silverlight, WP7)" - Have you seen the PortableLibrary effort? (blogs.msdn.com/b/bclteam/archive/2011/01/19/…) – Tangent

@MattDavey, hi there, no I haven't. Thanks for sharing the link. I work a lot with cross-platform WPF/Sl so anything that can assist in this area is good!! – Peroxidase