Hi mike bit confused - you're saying that the AccountService should load a SystemImplentation entity and add the account to it?
Sohnee seems to think that I'm not splitting the system correctly - what you're saying is to not split it at all? But then I'd have no benefit of soa at all? w:// On Fri, Oct 22, 2010 at 11:19 AM, Mike Scott <[email protected]>wrote: > It looks like you're describing an <a href="http://en.wikipedia.org/ > wiki/Anemic_Domain_Model<http://en.wikipedia.org/%0Awiki/Anemic_Domain_Model>">anemic > domain model</a>. > > The account service should perform all the operations on accounts, by > loading account domain objects and then calling methods on these > objects to implement the operations. The service should do little > other than orchestrate the loading of accounts and then delegating to > methods on them. Udi's article which you quoted gives an example of > this. Ideally the service should make a single call to a domain object > for each domain operation. > > You shouldn't have a SystemImplementationService. > > On Oct 21, 10:53 am, Wayne Douglas <[email protected]> wrote: > > I've asked this ( > http://stackoverflow.com/questions/3985893/soa-wcf-dissecting-the-sys...) > > question in relation to this topic, any help would be appreciated :) > > > > -------------------------->8--------------------------------------- > > > > I'm building a system which will have a few channels feeding different > > clients (MonoDroid, MonoTouch, Asp.Net Mvc, REST API) > > > > I'm trying to adopt an SOA archetecture and also trying to adopt the > > persistence by reachability pattern ( > http://www.udidahan.com/2009/06/29/dont-create-aggregate-roots/) > > > > My question relates to the design of the archetecture. How best to split > the > > system into discreet chunks to benefit from SOA. > > > > In my model have a SystemImplementation which represents the an > installation > > of the system iteself. And also an Account entity. > > > > The way I initially thought about designing this was to create the > services > > as: > > > > - SystemImplementationService - responsible for managing things > related > > to the actual installation itself such as branding, traffic logging > etc > > - AccountService - responsible for managing the users assets (media, > > network of contacts etc) > > > > Logically the registration of a new user account would happen in > > AccountService.RegisterAccount where the service can take care of > validating > > the new account (duped username check etc), hashing the pw etc > > > > However, in order to achieve persistence by reachability I'd need to add > the > > new Account to the SystemImplementation.Accounts collection for it to > save > > in the SystemImplementation service automatically (using nhibernate i can > > use lazy=extra to ensure when i add the new account to the collection it > > doesn't automatically load all accounts) > > > > For this to happen I'd probably need to create the Account in > > AccountService, pass back the unsaved entity to the client and then have > the > > client call SystemImplementation.AssociateAccountWithSystemImplementation > > > > So that I don't need to call the SystemImplementation service from the > > AccountService (as this, correct me if I'm wrong - is bad practise) > > > > My question is then - am i splitting the system incorrectly? If so, how > > should I be splitting a system? Is there any methodology for defining the > > way a system should be split for SOA? Is it OK to call a WCF service from > in > > a service: > > > > AccountService.RegisterAccount --> > > SystemImplementation.AssociateAccountWithSystemImplementation > > > > I'm worried i'm going to start building the system based on some > > antipatterns which will come to catch me later :) > > > > -------------------------->8--------------------------------------- > > > > Cheers > > > > w:// > > > > > > > > > > > > > > > > > > > > On Wed, Oct 20, 2010 at 7:14 PM, Thiago Alves <[email protected]> > wrote: > > > Consider the following example: > > > > > e.g.: consider an user with a list of blogs: > > > > > var user = session.Load<User>(1); > > > user.OwnedBlogs.Add(new WebLog { Title = "My blog #1", > Creator > > > = user }); > > > session.Update(user); > > > session.Flush(); > > > > > This code works but the user is actually loaded from the database (I > guess > > > that's because a property of the user instance is accessed thus the > proxy > > > loads the entity instance). > > > > > This other piece of code works just as expected: > > > > > var webLog = new WebLog { Title = "My blog #2", Creator = > new > > > User { ID=1 } }; > > > session.Save(webLog); > > > session.Flush(); > > > > > ... but in my domain model the User entity is an aggregate root for the > > > WebLog entity, so I would like to insert a new WebLog through the User > > > instance. > > > > > The relationship between User and WebLog (virtual public IList<WebLog> > > > OwnedBlogs { get; set; }) is mapped as a bag, with cascade="all" and > > > lazy="true" (lazy="extra" yields the same results) > > > > > Is there something conceptually wrong in the examples above? Is there > > > another way to accomplish what I want to do? > > > > > Thanks in advance > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "nhusers" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]<nhusers%[email protected]> > <nhusers%[email protected]<nhusers%[email protected]>> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/nhusers?hl=en. > > > > -- > > Cheers, > > > > w:// > > -- > You received this message because you are subscribed to the Google Groups > "nhusers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<nhusers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > > -- Cheers, w:// -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. 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.
