I was wondering if any of you had successfully implemented DDD in a Client/Server app and would like to share some experiences.
We are currently working on a smart client in Flex and a backend in Java. On the server we have a service layer exposed to the client that offers CRUD operations amongst some other service methods. I understand that in DDD these services should be repositories and services should be used to handle use cases that do not fit inside a repository. Right now, we mimic these services on the client behind an interface and inject implementations (Webservices, RMI, etc) via an IoC container.
So some questions arise:
should the server expose repositories to the client or do we need to have some sort of a facade (that is able to handle security for instance)
should the client implement repositories (and DDD in general?) knowing that in the client, most of the logic is view related and real business logic lives on the server. All communication with the server happens asynchronously and we have a single threaded programming model on the client.
how about mapping client to server objects and vice versa? We tried DTO's but reverted back to exposing the state of our objects and mapping directly to them. I know this is considered bad practice, but it saves us an incredible amount of time)
In general I think a new generation of applications is coming with the growth of Flex, Silverlight, JavaFX and I'm curious how DDD fits into this.
I would not expose repositories directly to the client. The first big problem as you mention is security: you can't trust the client, so you cannot expose your data access API to potentially hostile clients.
Wrap your repositories with services on the server and create a thin delegate layer in the client that handles the remote communication.
Exposing your Entities is not necessarily a bad practice it's just that it becomes problematic when you start to factor in things like lazy loading, sending data over the wire the client doesn't need, etc. If you write a DTO class which wraps one or more entities and delegates get/set calls you can actually build up a DTO layer pretty quickly, especially using code generation available in most IDEs.
The key to all of this is that a set of patterns should really only apply to a part of your application, not to the whole thing. The fact that you have rich logic in your domain model and use repositories for data access as part of DDD should not influence the client in any way. Conceptually the RIAs that I build have three layers:
Client uses something like MVC, MVP or MVVM to present the UI. The Model layer eventually calls into...
What I might call the "Integration Layer." This is a contract of services and data objects that exist on both the client and server to allow the two to coordinate. Usually the UI design drives this layer so that (A) only the data that the client needs is passed to it and (B) data access can be coarse-grained, i.e. "make one method call for all the state needed for this set of UI.
Server using whatever it wants to handle business logic and data access. This might be DDD or something a little more old school, like a data layer built using stored procs in the DB and a lot of "ResultSet" or "DataTable" objects.
The point really is that the client and server are both very different animals and they need to vary independently. In order to do so, you need a layer inbetween that is a fair compromise between the needs of the UI and the reality of how things might need to be on the server.
The one big advantage that Silverlight/WPF and JavaFX have over Flex + anything is that you can use a lot of logic in the first two because you have the same VM on both sides of the app. Flex is the best UI technology hands down but it lacks a server component where code could be shared and re-used more effectively.
Related
I have a DDD application and I am trying to understand where SignalR fits in my layers:
1. Presentation (Angular)
2. Distributed Services (Web API)
3. Application
4. Domain
5. Data
Basically, my SignalR hub notifies clients (Angular web app) when there is new data. For which I run a background service in a background thread that checks the database on an interval and notifies clients when there is new data.
I am inclined to think in this way:
The SignalR hub belongs to the Presentation layer. Given that my presentation project is purely client-side (Angular), I would add a new project under Presentation just for the hub.
The background service that checks the database on an interval seems appropriate for the Application layer. I would inject an INotify interface with a Notify method, which I would implement with SignalR.
Is this along the DDD principles?
DDD is all about ensuring that changes to your data only happen in a well-defined way, and where the code that executes those changes is defined in terms from a Ubiquitious Language which is well-understood throughout the whole business (not just the dev team).
DDD is silent on the mechanism used to interface with your users and other systems, other than recommending a layered architecture - which it sounds like you're already doing.
So - I wouldn't worry too much about DDD here - but it is worth considering your overall architectural approach - and in terms of layered architectural patterns, one that matches well to your approach is called Ports & Adaptors or Onion architecture. (see 1 and 2)
In this architecture, the outside of your system is considered as a set of adaptors that adapt between specific technology and your application layer. In your case your WebAPI layer is an example of an adaptor.
I would recommend creating a new SignalR adaptor - you can consider it at the same 'level' as the WebAPI adaptor (although in ports and adaptor parlance it's an 'output' adaptor, so you might diagram it on the bottom right of the onion).
In terms of the location of your background process - personally I would not consider that a part of the application layer, as it does not guide any use cases or process flows in your application. So, you could put it in your SignalR adaptor, or create a new dedicated component for it.
That said, you may find another concept from DDD useful - DomainEvents - they could remove the need for the background thread altogether. In your SignalR adaptor, include event handlers that register to handle DomainEvents, and in those handlers, propagate the information about the event via SignalR to your client side presentation layer - no need to poll the database at all! (Warning - depending on your domain event implementation, you may need to consider the risk of advertising events via SignalR before the aggregate is successfully persisted... but that's a whole 'nother topic.)
In an effort to understand MVC 2 and attempt to get my company to adopt it as a viable platform for future development, I have been doing a lot of reading lately. Having worked with ASP.NET pretty exclusively for the past few years, I had some catching up to do.
Currently, I understand the repository pattern, models, controllers, data annotations, etc. But there is one thing that is keeping me from completely understanding enough to start work on a reference application.
The first is the Service Layer Pattern. I have read many blog posts and questions here on Stack Overflow, but I still don't completely understand the purpose of this pattern. I watched the entire video series at MVCCentral on the Golf Tracker Application and also looked at the demo code he posted and it looks to me like the service layer is just another wrapper around the repository pattern that doesn't perform any work at all.
I also read this post: http://www.asp.net/Learn/mvc/tutorial-38-cs.aspx and it seemed to somewhat answer my question, however, if you are using data annotations to perform your validation, this seems unnecessary.
I have looked for demonstrations, posts, etc. but I can't seem to find anything that simply explains the pattern and gives me compelling evidence to use it.
Can someone please provide me with a 2nd grade (ok, maybe 5th grade) reason to use this pattern, what I would lose if I don't, and what I gain if I do?
In a MVC pattern you have responsibilities separated between the 3 players: Model, View and Controller.
The Model is responsible for doing the business stuff, the View presents the results of the business (providing also input to the business from the user) while the Controller acts like the glue between the Model and the View, separating the inner workings of each from the other.
The Model is usually backed up by a database so you have some DAOs accessing that. Your business does some...well... business and stores or retrieves data in/from the database.
But who coordinates the DAOs? The Controller? No! The Model should.
Enter the Service layer. The Service layer will provide high service to the controller and will manage other (lower level) players (DAOs, other services etc) behind the scenes. It contains the business logic of your app.
What happens if you don't use it?
You will have to put the business logic somewhere and the victim is usually the controller.
If the controller is web centric it will have to receive its input and provide response as HTTP requests, responses. But what if I want to call my app (and get access to the business it provides) from a Windows application which communicates with RPC or some other thing? What then?
Well, you will have to rewrite the controller and make the logic client agnostic. But with the Service layer you already have that. Yyou don't need to rewrite things.
The service layer provides communication with DTOs which are not tied to a specific controller implementation. If the controller (no matter what type of controller) provides the appropriate data (no mater the source) your service layer will do its thing providing a service to the caller and hiding the caller from all responsibilities of the business logic involved.
I have to say I agree with dpb with the above, the wrapper i.e. Service Layer is reusable, mockable, I am currently in the process of including this layer inside my app... here are some of the issues/ requirements I am pondering over (very quickly :p ) that could be off help to youeself...
1. Multiple portals (e.g. Bloggers portal, client portal, internal portal) which will be needed to be accessed by many different users. They all must be separate ASP.NET MVC Applications (an important requirement)
2. Within the apps themselves some calls to the database will be similar, the methods and the way the data is handled from the Repository layer. Without doubt some controllers from each module/ portal will make exactly or an overloaded version of the same call, hence a possible need for a service layer (code to interfaces) which I will then compile in a separate class project.
3.If I create a separate class project for my service layer I may need to do the same for the Data Layer or combine it with the Service Layer and keep the model away from the Web project itself. At least this way as my project grows I can throw out the data access layer (i.e. LinqToSql -> NHibernate), or a team member can without working on any code in any other project. The downside could be they could blow everything up lol...
I used to create normal webservices in my websites, and call these services from javascript to make ajax calls.
Now i am learning about Ado Data Services,
My question is:
Does this Ado Data Services can replace my normal webservice in new sites i will create?
And if Yes,
Can i put these Ado Data Services in a separate project "local on the same server" and just reference from my website? "to use the same services for my websites internal use and also give the same services to other websites or services, the same as twitter for example doing"
depends what you want to do , I suggest you read my conversation with Pablo Castro the architect of Ado.Net Data Services
Data Services - Lacking
Here is basically Pablo's words.
I agree that some of these things are quite inconvenient and we're looking at fixing them (e.g. use of custom types in addition to types defined in the input model in order to produce custom result-sets). However, some others are just intrinsic to the nature of Data Services.
The Data Services framework is not a gateway to a database and in general if you need something like that then Data Services will just get in the way. The goal of Data Services is to create a resource model out of an input data model, and expose it with a RESTful interface that exposes the uniform interface, such that every unit of data in the underlying model ("entities") become an addressable resource that can be manipulated with the standard verbs.
Often the actual implementation of a RESTful interface includes more sophisticated behaviors than just doing CRUD over the data under the covers, which need to be defined in a way that doesn't break the uniform interface. That's why the Data Services server runtime has hooks for business logic and validation in the form of query/change interceptors and others. We also acknowledge that it's not always possible or maybe practical to model absolutely everything as resources operated with standard verbs, so we included service operations as a escape-hatch.
Things like joins dilute the abstraction we're trying to create. I'm not saying that they are bad or anything (relational databases without them wouldn't be all that useful), it's just that if what's required for a given application scenario is the full query expressiveness of a relational database to be available at the service boundary, then you can simply exchange queries over the wire (and manage the security implications of that). For joins that can be modeled as association traversals, then data services already has support for them.
I guess this is a long way to say that Data Services is not a solution for every problem that involves exposing data to the web. If you want a RESTful interface over a resource model that matches our underlying data model, then it usually works out well and it will save you a lot of work. If you need a custom inteface or direct access to a database, then Data Services is typically not the right tool and other framework components such as WCF's SOAP and REST support do a great job at that.
I've just recently learned the PureMVC framework, and am a little confused as to the coupling between Proxy and Mediator objects. The links on this page connect to some documents describing the framework. (Please note, the links on the aforementioned page open PDFs.)
The diagrams and examples of PureMVC I've examined often show a direct coupling between a Mediator and Proxy. When the proxy's state is updated, rather than sending a new Notification, the Mediator (which retrieves a reference to the Proxy from the Facade) has its state updated.
This certainly seems to simplify the logic of the code, but it also directly couples two seemingly disparate components together. To my understanding, a Mediator's purpose is to translate Events from a view into PureMVC Notifications. Proxies are meant to perform some function to gather data and relay it back to the view. These two components seem to exist in different layers of the application, and perhaps shouldn't necessarily be coupled together.
Wouldn't it make more sense to have the Proxy objects send their own Notifications when their state updates, which are forwarded to the interested Mediator by the Facade?
Even if you update the mediator through notifications it would be coupled to the proxy but that's ok, it has to be.
As long as you don't couple the proxy i would say it's ok.
Juan
Wouldn't it make more sense to have the Proxy objects send their own Notifications when their state updates, which are forwarded to the interested Mediator by the Facade?
Yes, this is exactly what needs to happen. PureMVC is simply a Notifier / Observer pattern implementation with a lightweight MVC structure linked by a Facade. I strictly advise not to couple Proxies to Mediators; only allow Mediators to respond to Notifications that are sent by the Proxy when the data state changes. This allows those classes to be fully decoupled.
If you are using Flex, I would recommend HydraMVC / HydraFramework which is a Flex-specific port of PureMVC MultiCore, mimicking the API of PureMVC however is much less verbose, and includes a way to decouple server interaction from Proxies via a DelegateRegistry. (Full disclosure, I am the principal developer on this project, however it is fully OSS and free to use / contribute.) Regardless which MVC framework you implement, I still strongly recommend fully decoupling Proxies / Mediators via Notifications.
I've read some books on creating stateless websites, I've read some about stateful client applications, but a lot of complexity comes along when you have to combine both. We have a Flex application that needs to persist data to a database via .NET services. Things to keep in mind are:
- Concurrency (optimistic/pessimistic)
- Performance: Flex needs to load in lots of data so lazy-loading is often necessary.
- Do you use Dto's to tranfer data between server and client?
I'll tell you the history of our product. We've used SubSonic from the beginning as a o/r mapper. SubSonic objects are converted to dto's written by us and these dto's are transferred to the client. Clientside the dto's are converted to the domain model. If clientside a domain model object needs to be saved, it is converted back to a dto and send to the server. Server side the dto is converted to a subsonic object and saved to the database.
Now, some time ago, we needed the domain model on the .NET server side... so now we have like three models on the server side, the subsonic model, the dto model and the domain model. The dto model is more simple and resembles the database more, the domain model has much more logic. It gets complex... We now have to synchronize the AS3 domain model code with the C# domain model code. If we could do it again (of get time to refactor) I think we wouldn't use the dto's anymore, but transfer the domain model between client and server. Question is if this is realistic. Dto's are simple objects so easy to transfer. Domain model objects can be very complex.
Are there books on how to create an architecture for these kind of applications? Books writte by someone with lots of experience? Do you have experience with this?
The reality is that sharing objects between the client and the server is quite complex. Here's what you need to make it happen:
The easy/non-scalable way:
Inherit all of your objects from MarshalByrefObject. If you create Object A on the server, and send it to the client, any client modifications to the object will automatically be forwarded to the server.
While this sounds like the perfect solution, it has two major problems:
The client and server are tightly coupled with .NET (bye-bye Web Services)
It can be a performance nightmare. All method/property access will be forwarded to the server. If you choose this route, your objects should really be designed for chunky calls, not chatty ones.
The scalable/hard way:
Instead of using MarshalByRefObject, you would use DataContract/Serializable objects. However:
If you create Object A on the server, and send it to the client,
the client will receive a copy of the object (let's call it Object B)
When you send Object B back to the server, the server will receive a
copy of Object B (let's call it Object C)
But you really want the server to treat Object A and Object C as the same. Unfortunately, the CLR cannot do this, so you'll need an Object Merger to sit on both the client and the server.
The Object Merger would contain a dictionary of all objects within the model, and know how to identify two instances as being the same, and merge any values from the receiving end. For instance, if the client already has Object C in memory, and receives an updated copy from the server, it would copy over the values.
Unfortunately, this is also fraught with problems, because you need to ensure that object references are preserved correctly. You can't just blindly update all properties on an object, because the object may have existing references to other objects, which in turn may require their own merging. On top of all this, you would also need to track added/removed objects contained in lists or dictionaries.
I adding n-tier support to my own framework, so I'm going through the same exercise right now (I'm taking the "scalable/hard" route). Fortunately, I have a lot of the supporting infrastructure in-place to assist with identification, merging, etc. If you're starting from scratch, it would be a significant piece of work.
P.S. Add lazy-loading proxies into the mix (I'm using Nhibernate), and it gets even more interesting...
Go read anything by Fowler, particularily his design patterns stuff (especially the assembler pattern and why you need what you are already doing)
Fowler's Patterns Of Enterprise Application Architecture