Question about BOS and WPF

Nov 14, 2011 at 3:02 PM

Hello,

I was wondering what's the best approach to develop my WPF application... I've migrated a demo applicaton from SL to WPF and I've created a DevForce n-Tier WPF Application ... the first question I got is:

if I create a EDMX file in the server, I can interact with it adding a reference to the server (reference, not service reference) or I can add a svc and access with WCF..?

I've also created for test a DevForce BOS Web Application and added a Service reference to the WPF project, these seems to me the best approach since the "clients" don't know from where the data are

How does this cope with modularity? is this the correct approach? a server that contains the EDMX and exposes data via WCF? even in a WPF application?

Thanks

 

Coordinator
Nov 14, 2011 at 10:18 PM

Why would you want to access it via WCF? WPF is no different from Silverlight as far as DevForce is concerned. You still access your data through an EntityManager talking to a BOS. The only difference is that with WPF you can either run 2-tier or n-tier. In 2-tier mode, a lightweight BOS starts up inside of the WPF process, where as in n-tier you have a server-side BOS that the WPF app connects to. In addition, in WPF you can write your code synchronously, although we still recommend writing the code asynchronously in order to get a fluid and responsive UI. Users hate when the UI freezes up, while the app is waiting for a response from the server.

You should not put your edmx directly into the web project. Instead create a seperate assembly, so you can reference it from the WPF client as well as the Web project. You don't want to reference the entire Web project in your WPF client.

Nov 15, 2011 at 8:06 AM

Hello marcelgood,

thanks for your reply, by the way I've got still some question about putting the things together.... ok for the Model in a separate assembly, that's ok...and also ok for the async pattern...

If I put the EDMX in an assembly or in a WPF project, each client will have access to the DB directly... in other solution I've developed I've got a Web Server that acts as a BOS exposing the data trougth a WCF service... , can't the edmx beign exposed by wcf?

Thanks

Coordinator
Nov 15, 2011 at 8:19 AM

DevForce already communicates via WCF to a BOS. You can certainly write your own WCF layer if you want to or use our OData support to expose it via OData, but you are giving up the cache and the richness of our entities on the client. All the validation, change tracking etc. support that's built into our entities you will have to build by hand yourself and you will have to build your own cache. While a WPF client that has the whole model in there can theoritically access the DB, the client still requires a connection string to the database, permissions to access the database and the database must be accessable through the firewall. If you don't like the WPF client having the full model in there, you can use the same approach as in Silverlight. You can create a client model assembly, that only has the model classes linked in there and a server model assembly, which has the model classes plus the edmx. It's completely up to you of how much you want to pack in the client.

Nov 15, 2011 at 8:25 AM

Hello marcelgood,

thanks again..... since I'm new to this approach I wish to choose the best ... so you suggest me to put the EDMX in a separate assembly and reference it to the WPF application.... in the case of modules (for caliburn micro) each module should have it's own EDMX assembly? one for search one for orders and so on? (macro-modules) ?

This approach also work for enterprise application?

Thanks

Coordinator
Nov 16, 2011 at 6:44 PM

Yes, I recommend you put your edmx in seperate assemblies then reference it from the WPF client as well as the Web project. That way you keep the flexilibty of running 2-tier or n-tier.

As for edmx per module, we've already discussed this here: http://devforcecaliburn.codeplex.com/discussions/278570. The same applies to a WPF application.

Nov 17, 2011 at 9:50 AM

In the true, the web server it was created just to expose data... in that way I see no need of creating it... I'm still strugling on accessing the data from WPF directly instead of having a webserver doing that...

Thanks

Coordinator
Nov 17, 2011 at 6:57 PM

We have customers that don't want to maintain a server, so 2-tier cuts out the need for a seperate middle-tier. If you always want a server, then create two assemblies per model. One with the edmx and the other one with just the generated classes. You reference the one with the edmx on the server and the one without the edmx on the WPF client. Just like one does in Silverlight. I'm not sure what part you are still struggeling with, because this is no different from how we must do it in Silverlight, so I created a very simple example against our NorthwindIB DB and put it on my Skydrive.

It demonstrates the DevForce setup as described. There's a DomainModel.Server assembly that contains the edmx and the generated code. It's referenced by the Web project. Then there's a DomainModel.Client assembly that has the generated classes linked and is referenced by the WPF project. Notice that in the assembly properties, both DomainModel.Server and DomainModel.Client have the same default namespace, but different assembly names. Make sure you set yours up the same way.

https://skydrive.live.com/redir.aspx?cid=b37183c914f0fbe8&resid=B37183C914F0FBE8!187

Nov 18, 2011 at 9:17 AM

 

Hello Marcelgood...  your example is a step forward in what I want to achieve but I'm not really on this... in the example you've provided a the query    v

 

var em = new NorthwindIBEntities();
List customers = em.Customers.ToList();

MessageBox.Show(string.Format("{0} customers found.", customers.Count));

it's executed on the WPF client or on the server?

I wish that the WPF client communicates only with the server, not to the DB directly (that's the reason why I wish to have the edmx on the server)... don't know if there's a fast way of implementing this ...

I would like to keep the devforce invoking pattern (ex em.SP_GET_CUSTOMERAsync(region) and having the onSuccess/onFailed action) but wrapping them into a service or somewhat that permits me to have

  • Each request pass trougth the server
  • The web server interact with DB
  • The response is sent to the WPF client


This permits me to : attach SL project to services really in a simple pattern
Can set some access/logging policy in one point without having to redistribuite the whole package

Is it possible? am I totally pointing in wrong direction?
Thanks

 

Coordinator
Nov 18, 2011 at 6:59 PM

What you describe is exactly what this does. The query em.Customers.ToList() is not executed on the WPF client. It's executed on the server. That's how DevForce works. The power of DevForce is the ability to compose a full LINQ query on the client and have that query serialized and sent over the wire to a server where it gets executed and then the resulting entities are sent back to the client, where they get cached in the DevForce entity cache and can be manipulated and modified and the changes can be sent back to the server to be saved to the DB. In addition, any LINQ query can be executed against the cache on the client if the data is already in the cache to save a roundtrip to the server. This generally results in much better performing applications than the typical service based approaches, where everything has to run through the server and the applications tend to make too many unnecessary roundtrips.

You can interecept all queries and saves on the server to do logging/security checks/policies you name it, or you can restrict what a client can actually query using things like named queries or query filters (all on the server). DevForce is not a service framework, although under the hood the communication between the client and the server takes place over a WCF service, but you never need to touch that service. It's all handled for you.

In my example, you can replace the WPF client with a Silverlight client and it works the same way. Except you couldn't do .ToList(), because all queries against the server in Silverlight have to be asynchronous. You can also execute queries asynchronous in WPF, which is what we actually recommend in order to get fluid and responsive UIs. A typical enterprise may have a back office application written in WPF and a customer facing application written in Silverlight and they both can talk to the same BOS and use the same model. If you want you can even have a WinForms client as well, or you can expose your model through OData on the server for any non-.NET clients.

You are really getting into how DevForce works questions. This discussion board is not meant for that. Please use our regular channels to contact support with any DevForce specific questions. They'll have more bandwidth than me to help you understand how DevForce works.

http://www.ideablade.com/company/contact-us.aspx

Coordinator
Nov 18, 2011 at 7:32 PM

Just to make this more clear. I've added a Silverlight client project to the example. I've now encapsulated the query in a repository, which I then use in the WPF and the Silverlight client to get the customers asynchronously. There's now a new DomainModel.Client.SL. Same as DomainModel.Client, it only contains the generated entity classes. Both DomainModel.Client and DomainModel.Client.SL now also contain the shared repository where I have the query.

Now the query is no longer composed directly in the code-behind of the view, instead both the WPF client and the Silverlight client use the repository to get the list of customers asynchronously and when the response comes back it displays the message.

        private void Test_Click(object sender, RoutedEventArgs e)
        {
            var repository = new Repository();
            repository.GetCustomersAsync(
                customers => MessageBox.Show(string.Format("{0} customers found.", customers.Count())),
                ex => MessageBox.Show(ex.Message));
        }

Again, this does not use the DevForce Application Framework. This is pure DevForce, but it starts showing how the abstraction layers in DAF came about.