Dear Alex, i need some idea on how to create and access domain from different applications. primarily i will three diff applications accessing same database,

  1. asp.net webforms for data entry
  2. calculation engine as windows service
  3. integration service as windows application or windows service.

my question is,

  1. do i need to create separate domain and domain builder class for each applocation separately or i can manage this by creating single domain which can be accessed by these three applications.
  2. if i can create a single domain, so how to acheive that. i mean how to make sure that what ever application runs first ,should build domain n other application should connect to this already built domain.

please suggest.

thanks

HAN

asked Nov 23 '10 at 08:43

HannanKhanji's gravatar image

HannanKhanji
54141317

edited Nov 23 '10 at 12:46

Alex%20Yakunin's gravatar image

Alex Yakunin
29714412


2 Answers:

Domains in DO4 aren't MBR objects, so they can't be shared: we decided to avoid this, since such a decision leads to interfaces that are "chatty by default".

So currently there is just one option: create the Domain in each application where you need it.

Later we're planning to implement "remote://" protocol allowing to connect to another Domain without facing issues with chattiness.

answered Nov 23 '10 at 15:01

Alex%20Yakunin's gravatar image

Alex Yakunin
29714412

Thanks alex, but i would certainly like to know the meaning of "chattiness".

(Nov 24 '10 at 00:42) HannanKhanji HannanKhanji's gravatar image

In such scenario i used this:

  1. Have some "application setup" (in winforms/wpf or similar) where i build my domain (with mode Recreate when creating application first time or Perform with option to select within some dropdown to which version i want to perform upgrade process (if DO Model have more then 1 released version)
  2. When domain is builded (rebuilded or upgraded) successfully then i start to using client application to access data (in asp.net / silverlight / ...) or windows service / web service.

This solution works for me well, because i always know what i am doing, when i re-building/upgrading domain and when not. Client apps has always setup mode to Validate to ensure that they do not "hurt" database.

Just my 2 cents.

answered Nov 23 '10 at 09:19

Peter%20%C5%A0ulek's gravatar image

Peter Šulek
492313236

edited Nov 23 '10 at 12:47

Alex%20Yakunin's gravatar image

Alex Yakunin
29714412

Peter,its really nice idea as far as upgrade is concerned. but i was bit looking from memory point of view. what i mean is, let us say all three aapps run in Validate mode, so should all three apps should create a domain using Domain.Build static method. so in memory there will be three different domains... i saw something in DO3.x where you have option to Connect to domain.i was looking for same in DO4.x... my only concern is shall all three apps should have separate domains accessign to same database. do we need to always create a domain for a new application?? thanks

(Nov 23 '10 at 09:53) HannanKhanji HannanKhanji's gravatar image

Achh, you mean that, dont understand well. I think you should always "build" instance of Domain, becuase if i understand you than each of your clients is in different .NET AppDomain, even in different system process, or not?

(Nov 23 '10 at 10:05) Peter Šulek Peter%20%C5%A0ulek's gravatar image

yes it will in diff domain. i bilieve i have only one option as alex mentioned, separate domain for separate applications.. thanks peter. alex.

(Nov 24 '10 at 00:32) HannanKhanji HannanKhanji's gravatar image
Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
toggle preview

Subscription:

Once you sign in you will be able to subscribe for any updates here

Tags:

×573
×4

Asked: Nov 23 '10 at 08:43

Seen: 2,316 times

Last updated: Nov 24 '10 at 00:42

powered by OSQA