Click here to Skip to main content
15,891,431 members

Comments by ShacharK (Top 70 by date)

ShacharK 26-Sep-13 10:21am View    
I don't see how implementing ISerializable is of any help. I have a custom object that exposes String instead of an object. I need it to be transparent, as if it never existed.

InternalStructureToStringSerializationObject should output a serialized string, and it could be initialized from a string as well.

Instead of: { "Output" : "EncryptedString" }, it should be serialized to "EncryptedString" only.
ShacharK 21-Jul-13 17:28pm View    
Thanks a lot for your help, I tried to avoid this solution as I find it not very elegant, but I guess it is not that bad after all...
ShacharK 21-Jul-13 15:20pm View    
Umm, Lets simplify things a little a bit. I can reduce the problem into that. (Although, I'm afraid that I'll be giving up on some measures of security).

I obviously need all my modules to be loaded during the initialization, as I need to resolve types that exist in modules that aren't loaded as dependencies.

Is there a better way to do that rather than the simple solution of loading all the modules that declare that they are defining types, and need to be loaded? Something like scanning the directory for them when initializing the resolver mechanism?
ShacharK 21-Jul-13 1:35am View    
It knows only the base type, the rest is regular object population... I guess I might have re-implemented something, but it isn't the problem right now...
ShacharK 20-Jul-13 7:28am View    
Of course I'm going to use standard serializers. I wrote my own JsonConverter that knows how to resolve my types, All I need to do is to translate the type of the member that is being populated. If it inherits some base class that has "Id" member, I query the "Id" value and translate it into a new type (I assert for assignability of course...). Then I simply populate the new type instead.

My architecture would look something like this:

Common:
Contains lots of stuff, mostly irrelevant. Mostly wrappers (Reflection, Cryptography wrappers) Also some Error Logging & Asserts, Debugging Utils).

Common.Serialization:
Contained within the Common.dll, exposes a BaseSerializer class, that all serializers must implement, along with the base type for the polymorphic serialization, the identification attribute and the resolver code, which can be used by inheriting Serializers.
Plugins.Serializers.Json: A separate DLL. Implements JsonSerializer (simple wrapper to an existing serializer).

Plugins.Communication.Protocol - Exposes a Command design pattern, with some basic classes, mostly dealing with authentication abstractly.

Plugins.Authentication.Email - Examples for a plugin that implement authentication logic using an email-address and password.
Plugins.Authentication.Email.Protocol - Implements the abstract classes needed for authentication by the forementioned protocol.

Use case in an Application:

The application is configured to use JsonSerializer along with the protocol.

It needs to know to resolve types from Plugins.Authentication.Email.Protocol lazily, if it exists. I just don't want the application to specify the modules it requires manually in any step (especially not the protocol which shouldn't be related to any project and technically be compiled once for several projects).

The only thing I could probably live with is loading the assemblies manually in my executable project, but I really prefer not to do so, as I'm trying to achieve a black-box framework that my project developers could use without touching my code at all, just write / add existing plugins wherever possible.

Thank you again :)