Design question
-
OK, I am asking this here because it is more general architecture based than language specific based... I have a design I am working on that involves a Silverlight wizard style interface on a web form that makes calls out to a series of web services hosted in a windows service application. I have a design decision to make… The UI is a type of wizard style, multiple screens for each area of the process, and the process can be based upon some specific HW that is installed on the client machine that the website is viewed on. The main page makes a service call to the hosted application to get a device capabilities list and from there it knows what HW is available and then makes more service calls to talk to the HW and get a response back. All this because I can’t use an out of bowser Silverlight application to talk to the HW. Not a big deal but it poses a question for me… My original thought was to use a single Webservice method for the interface, pass in a series of commands and arguments formed as general Strings and KeyValuePairs, do some processing and then the web method returns a general set of KeyValuePairs again as the process results. In one way this sounds good for me because it allows me to make changes as I need to add functionality latter on, keep the older string values and just add new ones as I need without altering the code interface at all. It takes away some nice Intellisense in the editor but in the long run I was thinking that the flexibility was worth it. One other way I was considering was just biting the bullet and create a separate generic web method for each major functional part and then use the ability in the app.config file to select and load satellite assemblies dynamically based upon the requested version of the HW/Component/etc… Keeps the code a bit cleaner, allows for more use of Intellisense as I edit code and maybe even offers a bit more flexibility to add new devices, but places a heavier load on the use of the app.config file than I was looking for. Anyone here have a personal preference or some feedback about these methods, or maybe a third alternative that I had not considered yet?
-
OK, I am asking this here because it is more general architecture based than language specific based... I have a design I am working on that involves a Silverlight wizard style interface on a web form that makes calls out to a series of web services hosted in a windows service application. I have a design decision to make… The UI is a type of wizard style, multiple screens for each area of the process, and the process can be based upon some specific HW that is installed on the client machine that the website is viewed on. The main page makes a service call to the hosted application to get a device capabilities list and from there it knows what HW is available and then makes more service calls to talk to the HW and get a response back. All this because I can’t use an out of bowser Silverlight application to talk to the HW. Not a big deal but it poses a question for me… My original thought was to use a single Webservice method for the interface, pass in a series of commands and arguments formed as general Strings and KeyValuePairs, do some processing and then the web method returns a general set of KeyValuePairs again as the process results. In one way this sounds good for me because it allows me to make changes as I need to add functionality latter on, keep the older string values and just add new ones as I need without altering the code interface at all. It takes away some nice Intellisense in the editor but in the long run I was thinking that the flexibility was worth it. One other way I was considering was just biting the bullet and create a separate generic web method for each major functional part and then use the ability in the app.config file to select and load satellite assemblies dynamically based upon the requested version of the HW/Component/etc… Keeps the code a bit cleaner, allows for more use of Intellisense as I edit code and maybe even offers a bit more flexibility to add new devices, but places a heavier load on the use of the app.config file than I was looking for. Anyone here have a personal preference or some feedback about these methods, or maybe a third alternative that I had not considered yet?
With the first method you end up with a monolithic interface that will be difficult to maintain over time. You don't have to give up Intellisense if the objects being passed are serialized/deserialized representations rather than just generic name/value pairs. However, you do have the added complexity in the other method of creating/maintaining all of the assemblies but I think it would be the better approach, or at least the one I would try. In either case Intellisense support wouldn't be a concern. We programmed without just fine for many years.
I know the language. I've read a book. - _Madmatt
-
OK, I am asking this here because it is more general architecture based than language specific based... I have a design I am working on that involves a Silverlight wizard style interface on a web form that makes calls out to a series of web services hosted in a windows service application. I have a design decision to make… The UI is a type of wizard style, multiple screens for each area of the process, and the process can be based upon some specific HW that is installed on the client machine that the website is viewed on. The main page makes a service call to the hosted application to get a device capabilities list and from there it knows what HW is available and then makes more service calls to talk to the HW and get a response back. All this because I can’t use an out of bowser Silverlight application to talk to the HW. Not a big deal but it poses a question for me… My original thought was to use a single Webservice method for the interface, pass in a series of commands and arguments formed as general Strings and KeyValuePairs, do some processing and then the web method returns a general set of KeyValuePairs again as the process results. In one way this sounds good for me because it allows me to make changes as I need to add functionality latter on, keep the older string values and just add new ones as I need without altering the code interface at all. It takes away some nice Intellisense in the editor but in the long run I was thinking that the flexibility was worth it. One other way I was considering was just biting the bullet and create a separate generic web method for each major functional part and then use the ability in the app.config file to select and load satellite assemblies dynamically based upon the requested version of the HW/Component/etc… Keeps the code a bit cleaner, allows for more use of Intellisense as I edit code and maybe even offers a bit more flexibility to add new devices, but places a heavier load on the use of the app.config file than I was looking for. Anyone here have a personal preference or some feedback about these methods, or maybe a third alternative that I had not considered yet?
I had a similar decsion to make earlier this year, and went with a single method in the web service. My method accepts the stored proc to call and all parameters for that stored proc in the form of a XML string. When I call the method, the service takes the xml string containing the parameters, and creates SQLParameter objects. I can pass any type of parameter necessary, and the method returns data back as XML. It's all very slick, and the web service itself is the lowest maintenance part of the whole system. We haven't had to add *anything* to it since it was originally implemented over eight months ago. I wrote a tip/trick about it: Pass Dynamic List of Parameters to Web Service[^]
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
With the first method you end up with a monolithic interface that will be difficult to maintain over time. You don't have to give up Intellisense if the objects being passed are serialized/deserialized representations rather than just generic name/value pairs. However, you do have the added complexity in the other method of creating/maintaining all of the assemblies but I think it would be the better approach, or at least the one I would try. In either case Intellisense support wouldn't be a concern. We programmed without just fine for many years.
I know the language. I've read a book. - _Madmatt
-
I had a similar decsion to make earlier this year, and went with a single method in the web service. My method accepts the stored proc to call and all parameters for that stored proc in the form of a XML string. When I call the method, the service takes the xml string containing the parameters, and creates SQLParameter objects. I can pass any type of parameter necessary, and the method returns data back as XML. It's all very slick, and the web service itself is the lowest maintenance part of the whole system. We haven't had to add *anything* to it since it was originally implemented over eight months ago. I wrote a tip/trick about it: Pass Dynamic List of Parameters to Web Service[^]
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997Very cool… going to have to consider looking into that... I was also running into issues with returning a KeyValuePair from a webservice. It seems like no matter what I did I could never get at the KVP data.... I could see it when I drilled down into the debug window but I had to go like 5-6 layers deep and no matter what I did in code I could not get there. The best option I could come up with was creating a custom class with a key and value method and then just returning a generic list of these. That seemed to work fine. Thanks.
-
Very cool… going to have to consider looking into that... I was also running into issues with returning a KeyValuePair from a webservice. It seems like no matter what I did I could never get at the KVP data.... I could see it when I drilled down into the debug window but I had to go like 5-6 layers deep and no matter what I did in code I could not get there. The best option I could come up with was creating a custom class with a key and value method and then just returning a generic list of these. That seemed to work fine. Thanks.
Ray Cassick wrote:
creating a custom class with a key and value method and then just returning a generic list of these
In my experience you shouldn't be sending generic types over the wire! This has only applied to WCF in my experience, specifically, but it seems to be a problem with parsing serialised generic objects on deserialisation, so I'm going to assume it's a bad idea in general. Plus seeing it in a service contract just gives me the heeby-jeebies, couldn't tell you why. :doh: Why not just a KeyValue[] ??
-
Ray Cassick wrote:
creating a custom class with a key and value method and then just returning a generic list of these
In my experience you shouldn't be sending generic types over the wire! This has only applied to WCF in my experience, specifically, but it seems to be a problem with parsing serialised generic objects on deserialisation, so I'm going to assume it's a bad idea in general. Plus seeing it in a service contract just gives me the heeby-jeebies, couldn't tell you why. :doh: Why not just a KeyValue[] ??
I didn't really mean use generics per-se... I meant just to keep the list simple. I define a basic class that allows you define a Key and Value pair of Key = int, Value = object, wrap that is a small class, provide some accessors and generic initialize, then build a list of those: List kvp = new List
-
I didn't really mean use generics per-se... I meant just to keep the list simple. I define a basic class that allows you define a Key and Value pair of Key = int, Value = object, wrap that is a small class, provide some accessors and generic initialize, then build a list of those: List kvp = new List
Ah, ok, generic as in the normal meaning, not the specific programming meaning (i.e. List<KeyValuePair> or List(Of KeyValuePair)), right, sorry - misunderstood you. In that case, if both ends are WCF, you should be able to cast the Value property objects when they come out the other end to their specific types (assuming you have access to them, i.e. you've included the assembly on the other end). If not I believe you would have to do some funky deserialisation code and manipulation of raw XML, yuck! I would stick with the D.A.D.S. principle when talking about objects going over the wire:
\[DataContract\] public class KeyValuePair { \[DataMember\] public **string** Key { get; set; } \[DataMember\] public **string** Value { get; set; } }I agree with Mark, though - why not use WCF? You get all the data types on the receiving end as "real" objects, no loss of Intellisense. Plus, it feels safer :) As for your original question/situation, that is a tough one - I'd need to think that one through for a while. I like to use role-play (just leave it ;) ) Walk yourself through the maintenance cycle with a pencil and paper, "you rolled a 5, new HW support required" or "you rolled a 2, implementation of HW type X changes" (no need for a die, that was purely for example). I find working through these situations helps me choose the easier path. Don't really know if that's what you're looking for... I have emptystomachitis, off to lunch!
-
Ah, ok, generic as in the normal meaning, not the specific programming meaning (i.e. List<KeyValuePair> or List(Of KeyValuePair)), right, sorry - misunderstood you. In that case, if both ends are WCF, you should be able to cast the Value property objects when they come out the other end to their specific types (assuming you have access to them, i.e. you've included the assembly on the other end). If not I believe you would have to do some funky deserialisation code and manipulation of raw XML, yuck! I would stick with the D.A.D.S. principle when talking about objects going over the wire:
\[DataContract\] public class KeyValuePair { \[DataMember\] public **string** Key { get; set; } \[DataMember\] public **string** Value { get; set; } }I agree with Mark, though - why not use WCF? You get all the data types on the receiving end as "real" objects, no loss of Intellisense. Plus, it feels safer :) As for your original question/situation, that is a tough one - I'd need to think that one through for a while. I like to use role-play (just leave it ;) ) Walk yourself through the maintenance cycle with a pencil and paper, "you rolled a 5, new HW support required" or "you rolled a 2, implementation of HW type X changes" (no need for a die, that was purely for example). I find working through these situations helps me choose the easier path. Don't really know if that's what you're looking for... I have emptystomachitis, off to lunch!
I still think my way of doing it is easier and much less maintenance intensive.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997