Is this valid? or does it smell?
What I'd want to do is:
Have a datacontract object that holds a friendly object tree that can be saved by the service layer without the GUI not having to worry about it.
At the GUI level I make heavy use of databinding and also have some GUI specific logic (like cloning, flagging as deleted, basic validations, INotifyPropertyChanged etc).
I'd like to extend this DataContract class so I just have to add BindingLists, or my specific GUI logic and then send this object without the need of translating it to the WCF service layer.
Maybe composition is a better approach than extending?
any ideas?
I wouldn't extend the DataContract class. I would create a Facade that added the extra functionality that I needed and could also handle communicating back down through the DataContract transparently.
Related
I am working on a WPF application using MVVM pattern. I need to do data validation(using Data Annotations) for my data entry screens.
But the tricky part to write a common piece of code is rather than using simple property I need to use properties with are calling GetValue and SetValue method. But my entities are being generated by entity framework using templates and modifying template to achieve this things seems very difficult.
I am using this technique to validate my data
http://blogs.microsoft.co.il/blogs/tomershamam/archive/2010/10/28/wpf-data-validation-using-net-data-annotations-part-ii.aspx
http://blogs.microsoft.co.il/blogs/tomershamam/archive/2010/10/11/notifyingobject-for-wpf-amp-silverlight.aspx
If there is better and authentic way to validate the entity data, i'll be more than happy to change my approach or if I need to change the template then please point me to some great reference.
Firstly. Really bad idea to do this, not because it is hard, but due to that you need to inherit DependencyObject. DependencyObject is an STA Threaded class. You won't be able to use a worker thread to instantiate your objects, which means you can't use a worker thread to use Entity Framework.
Now, I suggest you use the MVVM pattern with WPF. You should have a View bind to a ViewModel, which then binds to your Entity Framework POCO objects.
You can try IValidateObject for you validation https://stackoverflow.com/questions/13917890/mvc4-custom-validation-via-ivalidateobject-validate-method-not-working
I personally however prefer the FluentValidation library.
I have a Silverlight application that is loading Entities from a WCF Service via DataBinding.
So I have several views with many textboxes whose textboxes contents are binded to a Entity properties.
I want to use Silverlight validation and I don't want to use the exceptions way (I have some entities with a lot of properties... and I don't want to repeat it every time I use it in a form...).
So I'm triying to use the IDataErrorInfo way, but I'm not sure how should I do it.
I think I should declare a client-side model with equivalent classes to the Service EF Model but implementing the IDataErrorInfo. This solution means duplicate the model code and make any way to translate from service model to client model.
The other solution could be to change the EF Model itself but I don't know if this is correct for the MVVM (this is really near to the view, isn't it).
Maybe there is another magical solution I don't know.
Any suggestions??
The recommended interface is actually INotifyDataErrorInfo
Which gives you a little more control and supports multiple errors. It's also a little bit easier to use in scenarios when you manually want to control when validation happens.
Basically, with this, you could create a validate method on your "client side" objects which goes through their properties, validates each one, and builds up a list of errors. (HasErrors becomes true, you notify ErrorsChanged and then the code that binds to your object does GetErrors.
With this way, you could build a validation engine and have each EF object poll your database for validation rules.
There's also this: http://msdn.microsoft.com/en-us/magazine/ee335695.aspx
If you have the option of annotating your EF classes on the client side instead of simply using the generated ones, you may be able to find an easy solution here.
I know this is slightly off-topic since you're using WCF
but if you were to use RIA Services, then it generates objects from your EF, and you can simply add some attributes to them in the RIA (it comes with comments telling you which attributes to use)
and it's very very simple.
but that advice is relevant only if you were to use RIA.
If I am generating POCO objects from EntityFramework, and using these to go to/from the WCF server, is there any reason to create client-side Models for the Views & ViewModels to use instead of just using the POCOs directly?
Almost all the MVVM examples I have looked at bind straight to the object returned from the WCF service. Is this good practice? Are there arguments that can be made for actually mapping the POCO to a Model and having the Views/ViewModels working with the Model object instead of the POCO?
The main reason I could think of is validation, however since the EF POCOs are partial classes, they can be expanded on to include validation.
EDIT
Most answers so far have brought up INotifyPropertyChanged as the main reason to build a separate Model. Does your answer change if you are using Self-Tracking entities instead of POCOs which already includes INotifyPropertyChanged? STEs are also partial classes which can be expanded upon to include validation.
Validation is the main reason not to bind directly to a POCO. In addition, if the POCO doesn't already implement INotifyPropertyChanged and other required interfaces, the experience working with the object on the WPF side may be less desirable, and implementing a ViewModel to wrap this makes sense.
Providing a ViewModel to wrap your POCO allows you to encapsulate the logic into ICommand implementations as well as implement required interfaces cleanly.
I disagree only slightly with Reed (an unusual circumstance to be sure). I would NOT implement a ViewModel to wrap the POCO. I would implement a Model class to wrap the POCO and expose the Models to the ViewModel via a Service layer.
The ViewModel's primary job is to appropriately present Model data to the View and react to its requests. The architecture I'm working on for this looks like so:
1 ViewModel for each View
The ViewModel calls a Data Service layer object to retrieve Model instances (not to be confused with a WCF service)
The Data Service layer issues the appropriate CRUD requests to the backend (this uses WCF, RIA, or RESTful Services for Silverlight but could be ADO.NET or EF directly for WPF).
The Data Service uses the returned POCOs to create Model objects.
Model objects wrap the POCO object and implement INotifyPropertyChanged. Model objects enforce business rules.
I'm still working through the details but I will be publishing something more concrete in the near future.
My Models accept a WCF object which exposes those properties which I wish to use in my ViewModel. I can then also extend the object as needed. My properties point to the WCF object's property and when I have to send the object back to the WCF service, I don't have to do any more work. The models inherit INotifyPropertyChanged and INotifyDataErrorInfo which the DTOs (mentioned here as POCOs) will not have. Your business logic / validaton exists in your Silverlight application and not in your WCF Service.
The View binds to the ViewModel which has a Model (or an observable collection of Models). The Models have a WFCObject which is a DTO (mentioned here as POCO). I use my ViewModel to communicate with the service, MVVM Light has the models communicate with the service / provider - which I don't like.
Bind to EF POCOs if you want to do simple CRUD or you want to make something fast.
Otherwise, your server-side models will tend to be very closely related to the database, which changes very slowly, as compared to user interface. For less trivial UI, you'll find yourself putting more and more kludges just to fit your database model into UI (or otherwise, which is even worse).
Also, there are performance issues (e.g. would you like to transmit whole entity when for UI you need only couple of properties?), and maintenance issues (e.g. if you would like to validate premium customer's order quite differently from ordinary one).
See also http://ayende.com/Blog/archive/2010/08/06/data-access-is-contextual-a-generic-approach-will-fail.aspx
Rachel's POCO's are just dumb objects generated by EF and used for transport (DTO). Therefore, they shouldn't have other things cluttering up their domain. This is a very nice way of designing your code because it decouples any client-side requirements from those on the server-side. That's why MVVM exists - to extend the MVC model incorporating those concerns.
There is no reason you can't bind to them in your views as long as you are not modifying them directly. You can add functionality to them by adding a partial class but I wouldn't even do that. In that case you should follow the MVVM design tenants and separate those into model objects that serve your needs in the client. This will be quite automated once you hook up INotifyPropertyChanged events to notify your views.
In trying to design an architecture for a Silverlight application, I am at a point in asking is it better to:
use an Entity Data Model with a WCF Data Service and then put my business logic in the code-behind for my silverlight user control to do any modifying/managing of pure data returned from WCF Data Service
or
use an Entity Data Model with a WCF Service and then put my business logic in the actual service using [OperationContract] methods in which I can apply my business logic in the service level thereby providing a clean seperation between presentation (silverlight) and business (service)
Can anybody provide their opinion on which approach would be better or if there is yet a better approach that I have not discovered outside the scope of my suggestions above?
Thanks
I would, personally, use a combination of above (with modifications).
I would put the business logic and business rules, as appropriate, into your WCF service. This has many advantages, including allowing the service to do all of the data validation and checking (which it should, in any case), without requiring it to happen twice. This promotes reuse of your service for applications in the future, since the logic there is domain specific, and not tied to a specific presentation layer or application design.
That being said, I would not put logic specific to this application into the service. Instead, I would use an MVVM approach, and put the application-specific logic (separate from the business rules) into a ViewModel class, and use this from your Silverlight views. I would try to avoid using code-behind as a place to inject logic - whether application or business rule specific.
I wouldn't put the business logic in the actual service. The service is a Service Interface Layer
Essentially, it provides and interface (an API) between your "system" and the outside world. In this case your UI.
So you still need a business layer that has your logic. and the Service Interface layer talks to the business layer and surfaces the methods and data as a WCF Service.
So I'm looking for some clarification how it would be possible to remove the service locator from my application.
I have a ViewManagerService that is responsible for knowing which view is active, which views are open and creating a new view.
Currently my ViewModels get an IViewManagerService injected into them via constructor injection. These ViewModels expose ICommands that when invoked can then make a call to
viewManager.Transition("MyCoolView", somePrimaryKey);
The ViewManagerService then uses a service locator to look up and instantiate a new view with the key "MyCoolView". The reason for using a key string is so I can decouple the View from the ViewModels. I would like to keep the ViewManagerService generic enough so I can use it for other apps, so I don't want it to depend on a specific IAbstractFactory interface.
Any tips/suggestions ?
You can get rid of magic strings completely by using WPF's data templating engine. The best way to do that is to use the MVVM pattern. It's orthogonal to DI, but a great enabler.
Once you've made that transition, you can have a pure DI architecture without having to rely on the Service Locator anti-pattern.