Began to study WCF. For my test project I decided to make a three-part project: 1) a class library with all business logic and work from a database on LinqToSql; 2) WCF Service Library; 3) ASP.NET MVC client. Actually the snag arose in how best to organize communication LinqToSql - WCF. At the moment, the interfaces of my LinqToSql models:

interface IVisitor { DateTime DateOfBirth { get; set; } bool Gender { get; set; } string Name { get; set; } string Surname { get; set; } System.Data.Linq.EntitySet<Visit> Visit { get; set; } } interface IVisit { DateTime DateVisit { get; set; } long IdVisitor { get; set; } Visitor Visitor { get; set; } }

how best to transfer these classes to a WCF project and declare [DataContract] -s? To put down the attributes directly in the business logic project will be a bad tone, especially since you have to go into dbml designer. But will it be good for these interfaces in the wcf service project to implement the VisitorDataContract, VisitDataContract classes and in the service implementation to bring the model object into an object of this class? In essence, there will be duplication of code.

    1 answer 1

    If you call business logic a project that performs mapping of your database tables to Sharpov classes, then you are mistaken. This is not business logic, it is just a projection of database tables. Of course, there is no need to edit these classes in any way, let alone add the DataContact attributes to them. In any case, your layers (links, as you call them) should have the smallest possible level of connectivity with each other. These layers should interact with each other through some open interfaces, and be a separate module, any of which can be replaced without serious consequences by some other, without destroying the entire architecture. In other words, your business logic should not know anything at all about either the WCF project or the ASP.NET MVC project. WCF, in turn, should not know anything about ASP.NET MVC, and should not be tightly tied to specifically this layer of business logic (that is, business logic must provide a certain set of access points that WCF can use, while replacing your layer business logic on the other, with similar access points, should be painless). In this way, you will ease your life when changing, expanding and testing the project and get rid of the need to write crutches at the slightest lead. From this it follows that only WCF should work with DataContract, since DataContract is needed to serialize your data, and only WCF service needs serialization. The underlying layers (business logic, data layer) do not know anything about serialization, and therefore should not see it. The less you know - sleep tight, as you know. Since your WCF service will transfer some data to the outside, and it will obviously be taken from business logic, it will need to somehow serialize this data for the correct transfer. This is where DataContract comes in. You will need to create a class (or classes) with this attribute that will be used to serialize data from business logic. Moreover, it is far from necessary that these classes be full projections of each class from business logic, most likely it will not be necessary, otherwise you will get almost complete duplication of code. However, in general, some kind of duplication cannot be avoided, because it’s still not worth mixing serialization and business logic, these are different things, and they must be separated into different layers of your application.

    • > If you call business logic a project that performs mapping of your database tables to Sharpov classes, then you are mistaken. This is not business logic, it is just a projection of database tables. This is not business logic, it is part of business logic. I just showed the interfaces of the classes that should be serialized, and indicated that the serialization classes will turn out to be a complete projection of the model classes — in fact, because of this duplication, and I have doubts. So, in my business logic project, I already have a linq-query repository and data validation. The rest is understandable, thanks for the clarification - MaboUhha
    • Now I think that the best option would be this: <pre> public interface IVisitorsWcfService {... [DataContract] public class VisitorDataContract {public VisitorDataContract (Visitor visitor) {// fill the VisitorDataContract object with data from the Visitor}} </ pre> And in implement the service after calling the constructor, we are already working VisitorDataContract as we please - MaboUhha