My Project solution is as below:<ol><li>MVC Project (Containing reference of both projects listed below)</li> <li>WCF Service containing business methods (Containg reference of below listed project)</li> <li>Common Project for DTO or BusinessOBject</li> </ol>
IN MVC - Calling the WCF service method is as follow -
it is called from MVC - ServiceClient.RetrieveData() , now problem is return object
Employee point to
ServiceHost.Employee object instead of -
Common.DTO.Employee object (Library project) so, it gives type casting error.
Can any one suggest me what is the solution over here or i should remove "Common.DTO" project refernece from MVC and only use
Please guide me on this design, what should use.
NOTE: all objects are DATACONTRACT (serilizable).
In MVC applicaiton, after retrieing DTO object, i do convert them into Viewmodel (It also internally refer any collection object like
IList<ServiceHost.LookupItem> . Does it ok to use all generated serilized object directly OR , do i have to convert/cast each return object into
common.DTO. object and then convert into ViewModel ?
<strong>Don't</strong> use <em>Visual Studio's</em> <strong>Add Service Reference</strong>. Doing so will result in <em>multiple types</em> being defined in the solution and <em>client-proxies</em> that over time will become <em>out of sync</em>.
It is much better to define a common contracts assembly that your whole solution uses.
Please see <em><a href="http://www.devx.com/codemag/Article/39837" rel="nofollow" title="WCF the Manual Way…the Right Way">WCF the Manual Way…the Right Way</a></em> specifically page 3
You should try to follow patterns such as canonical data model whenever possible. This means the same type for POCO ORM; WCF; and as aggregates in your view model. Data conversion is expensive; leads to increased maintenance and possible fidelity loss. <a href="http://www.soapatterns.org/" rel="nofollow">http://www.soapatterns.org/</a> <a href="http://www.eaipatterns.com/" rel="nofollow">http://www.eaipatterns.com/</a>Answer2:
This really depends on what level of abstraction you want.
ServiceHost.Employee is your domain model and MVC is your presentation layer then it would make sense to use a DTO to bridge the gap here. Given that's the approach you seem to want to use then the solution would be to have
IList<Common.DTO.Employee> instead of