I have to refactor an application which has at almost every model and codebehind file an instance of serviceclient, and some of them use a serviceclient property from App.xaml.cs (Silverlight 4)
What is the best practice for this? Do it so, that all controls would use an instance of serviceclient kept in app.xaml.cs, or create at every viewmodel/codebehind an instance of serviceClient?
In coming few weeks (as I get an answer for my other question also) I need to write some unitests, so I need to keep this in mind.
As a best practice and a very hands-on approach to doing SL, MVVM and WCF, I would like to invite you to read and follow http://aviadezra.blogspot.com/2010/10/silverlight-mvvm-odata-wcf-data.html. Just perform this tutorial like steps and you will know how to perform your job.
Very specifically, about your question on where to create and maintain your service reference, the suggested approach is to create a static object called something like DalService that will be instanciated on first usage and just hang around and be available for any viewmodel to query the back-end.
Related
I'm not so much seeking a specific implementation but trying to figure out the proper terms for what I'm trying to do so I can properly research the topic.
I have a bunch of interfaces and those interfaces are implemented by controllers, repositories, services and whatnot. Somewhere in the start up process of the application we're using the Castle.MicroKernel.Registration.Component class to register the classes to use for a particular interface. For instance:
Component.For<IPaginationService>().ImplementedBy<PaginationService>().LifeStyle.Transient
Recently I became interested in creating an audit trail of every class and method call. There's a few hundred of these classes so writing a proxy class for each one by hand isn't very practical. I could use a template to generate the code but I'd rather not blow up our code base with all that.
So I'm curious if there's some kind of on the fly solution. I know nHibernate creates proxy classes at some point which overlay all the entity classes. Can someone give me some guidance on how I might be able to do something similar here?
Something like:
Component.For<IPaginationService>().ImplementedBy<ProxyFor<PaginationService>>().LifeStyle.Transient
Obviously that won't work because I can only use generics to generalize the types of methods but not the methods themselves. Is there some tricky reflection approach I can use to do this?
You are looking for what Castle Windsor calls interceptors. It's an aspect-oriented way to tackle cross-cutting concerns -- auditing is certainly one of them. See documentation, or an article about the approach:
Aspect oriented programming is an approach that effectively “injects” pieces of code before or after an existing operation. This works by defining an Inteceptor wrapping the logic being invoked then registering it to run whenever a particular set/sub-set of methods are called.
If you want to apply it to many registered services, read more about interceptor selection mechanisms: IModelInterceptorsSelector helps there.
Using PostSharp, things like this can be even done at compile time. This can speed the resulting application, but when used correctly, interceptors are not slow.
I have a direct question: Is a good pratice use Singleton pattern to control a class responsable for Login tasks, or another pattern is more appropriated? Or do not exist a patter to do this kind os issue?
Thanks.
Few people use singletons these days as they are almost becoming anti-patterns. I would recommend to learn Dependency Injection (DI).
With DI you can register the object you wish to use as singleton with a container and that container will serve or give that object to all other objects that need it. Of course you can register the object as a singleton - but not the usual singleton - and the container will guarantee that all objects which need it will receive the same instance.
Nevertheless, if you are building a small application then It would be better to use the Singleton pattern and avoid DI.
Jon Skeet has a very nice article about Singleton pattern or if you are using Java then you could use Enumerations to implement it, look implementations techniques on Google.
The singleton pattern is used when you have to prevent the creation of more than one instance of the same class. I do not really see the situation in which a login class should only have one instance so i would say using this pattern for a login class is overkill.
Then again, introducing a DI framework when you only need a simple singleton... now thats overkill :)
Yes and no. There's no 'best' or 'worse' practise.
Just do it, if using a singleton makes it easier to test and if the approach will get you to the pub earlier than learning and implementing DI just for the purposes of login.
I have a pretty serious problem. I have an application that has a partial class that is spread out across several folders in my Project. I am trying to create a daughter object that has all the functionality of this object (this is a WCF webservice and I want to make sure that I have all the functionality of that first service before I add on or expand on it). However, for some reason, after I inherit from that object I can't seem to access all the functionality of the first class? I am not sure what I am doing wrong? I can't show any real code segments because it is proprietary, but here is an example.
public partial class OriginalService : IwantThisThing2Work{ //In here the functionality of the Interface is implemented, I just don't feel like writing dummy functionality }
public partial class OriginalService : IwantThisThing2Fail{//In here the functionality of the Interface is implemented, I just don't feel like writing dummy functionality }
public partial class OriginalService : IsomeInterface{//In here the functionality of the Interface is implemented, I just don't feel like writing dummy functionality }
public class Secondservice : OriginalService {//All of the functionality should be in here}
Now, for some reason, I only seem to get the functionality of the first two and not the rest of the functionality. I am not really sure what else I can do? There is not a lot of documentation on the topic that I can think of. The only thing I can think of is maybe there are some dependecies that I am missing or something during compelation.
Any Ideas fellow coders?
You have not provided much information to go on here but I would check that namespaces of all the partial classes are consistent.
OK. I think I figured it out. I forgot to add all of the contract endpoints to my web.config file. I did in fact add the contract's for the two endpoints that I could access.
To be more clear, the person who wrote the original service divided his contract up among several smaller contracts (I guess to separate concern... or SOC). He implemented the contracts by creating one class but dividing it up using partial classes. When I attempted to change the security protocols of the WCF service by implementing WShttpBinding, I only tested the first two contracts he created and I only added those two endpoints. After struggling to get the WSHttpBinding working (setting up a certificate on the server and on my machine... Never did that before) I completely forgot to add the rest of the endpoints. So even though I implemented them in driver of the contracts, they would never be exposed, thus my weeping and nashing of teeth, and fear of Job losses for not being able to perform the simplest of tasks.
Just one more question, what do you guys think of the separation of contracts and implementing them through partial classes? Is that part of some design pattern that I am not aware of?
Thanks,
Idiot Developer.
Given the fact that I have a fully dynamic object model, that is, I have no concrete classes defined anywhere in code, but I still want to be able to create WCF DataContracts for them so I can use them in operations. How can I achieve this?
My concrete class "Entity" implements ICustomTypeDescriptor which is used to present the various properties to the outside world, but my expeimentation with WCF suggests that WCF does not care about ICustomTypeDescriptor. Is this correct or have I missed something?
Is this possible? It cannot be so that the only way to create a DataContract is to actually have a concrete harcoded class, can it?
you may use untyped service and message contract IIRC http://geekswithblogs.net/claeyskurt/archive/2008/09/24/125430.aspx
You might try System.Reflection.Emit.
Its quite tricky, but essentially you will just build a custom run-time type, with decorated data contract attributes. It gets tricky when creating encapsulated properties with PropertyChanged notifications, but in your service layer you can just get away with auto properties which are a lot easier.
This dated, but still very relevant link should get you going in the right direction.
http://drdobbs.com/184416570
Things evolve :-) Thanks to the excellent blog series by Alex D James its very easy to implement this.
I need to hook into the WCF operation process to execute some code right before and right after each operation.
Some context:
I already have a custom servicehost, servicehostfactory and servicebehavior
all my services are based on a common base class
I've been snooping around and I think using a IParameterInspector would be the best choice, but I'm not entirely sure given that the code I need to execute has nothing to with parameters...
Any clues?
IParameterInspector is not a bad choice.
Do you need to know which operation/session/endpoint is happening, or are you just installing the same logic for all operations? Do you need to modify the Message object? (These considerations may change your choice of extensibility point.)
Do you need to modify thread-local storage? If so, prefer ICallContextInitializer.