@Luis & Sebastian Lads, you still seem to be missing the point I am talking about :) I am not advocating this as a silver bullet, I am just saying that this is doable and it has some situations that make perfect sense for the sake of KISS.
Nothing is written in the stone, if something has to be religion this is my religion. You can use your domain entities fron NH as DTOs, with WCF, NServiceBus, MassTransit with no problems at all. I have done several applications in this way in the past, where they were applicable and we were no way practising any DDD - let alonde Distributed DDD. Please read the example I gave again, and don't complicate things with "yes, but what if" s. It has a UI box, which I do develop and control, it has a services tier connected with WCF which I develeop and control again. Services has no clients that are deployed to a box that I don't deploy and control. Domain is pretty simple, it is often an AR which are even sometimes bound directly to screen. And what I am telling is that, the amount of the applications out there that needs this simplicity is not very small you'll be surprised, this is the default architecture for most enterprise apps out there and very well distributed. And simple. When you are performing validation rules in all layers, valid entities are not problems since you are using the same of validation helpers in all tiers. If your entities are not valid in db, you won't pass it to client tier over the wire controlled by WCF. If it is passed somehow, they are gonna fail the validation that WCF client enforces on them, as John described. The danger and pain is not in following this path, they are in following it in irrelevant places. You have got to know why you are doing what you are currently doing in that way, and if it is worth the time you are spending on it or not (and if you should spend from budget to do that). I somewhat have the urge to repeat it again, that I am not saying that this is the procedure that I always follow. There has been situations in the past that this model has brought team into speed, and the scenario is from real life. As a consultant, I need to deliver the best to the project, and always keep the context in mind, not only spread my religion around. On Thu, Oct 30, 2008 at 12:04 PM, John Rayner <[EMAIL PROTECTED]>wrote: > > We use WCF serialization against our domain entities. We ensure valid > state by only using full serialization on objects being retrieved from > the service. Update / Delete operations are handled by the WCF client > passing our service a Command object. The service then loads the > domain entity and applies the relevant update / delete action. > > Cheers, > John > > On Oct 30, 10:38 am, Sebastian Jancke > <[EMAIL PROTECTED]> wrote: > > Sidar, > > > > as you said, it may make sense, when in a small environment. However for > > historic reasons - plus always having domain objects in valid state - > > there is no way around for me to bind domain objects to the ui or > > services. In your described UI-szenario, there seem to be no wcf > > services aground. So coming back to the initial question, going > > distributed with e.g. wcf seems not simple/trivial/small to me. > > > > -Sebastian > > > > Sidar Ok schrieb: > > > > > > > > > Windows forms client apps is multiple clients. It is not the count of > > > the type, it is the number of consumers of your services. > > > > > An example to what I said is a multi tier web application, where you > > > develop both UI and services. So that when an entity is changed, yo > > > don't need to change your mappings because simply the same thing is > used > > > everywhere, even while binding to UI. There are lots of projects out > > > there that this quick and dirty model is enough. > > > > > Hope it all makes sense. > > > > > Sidar > > > > > On Wed, Oct 29, 2008 at 10:15 AM, Luis Abreu <[EMAIL PROTECTED] > > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > > Hello guys. > > > > > Sidar, even in simple projects where you only have a client you'll > > > have some gains if you don't distribute your domain objects. I was > > > distributing domain objects happilly until one day I've noticed > that a > > > really small bug correction meant having to redistribute > everything, > > > ie, besides updating my service layer, I had also to update the > > > windows forms client apps. This can be a pain in the ass if youi > don't > > > have high width badwith (l have several clients which use our app > and > > > don't have high width bandwidth)... > > > > > So, that's why now we will always use DTOs for sending info back to > > > the client. Generally, they're more stable than our domain objects > and > > > this means less coupling and less worries with clients updates... > > > > > -- > > > Regards, > > > Luis Abreu > > > > > -- > > > Sidar Ok > > >http://www.sidarok.com > > > > > > > > sebastian_jancke.vcf > > < 1KViewDownload- Hide quoted text - > > > > - Show quoted text - > > > -- Sidar Ok http://www.sidarok.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to nhusers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
