There is a client-service application that uses WCF to build service-oriented architecture and DDD to build domain layer inside the service.
In the Domain Layer there is a domain object Customer with methods:
to change Phone and Address Customer.Relocate(Phone, Address)
to assign Sales Manager to a Customer Customer.Assign(SalesManager)
to make Discount to a Customer Customer.Make(Discount)
Since this Domain Layer is used inside a WCF Service, CustomerService is created with service methods:
CustomerService.Relocate(CustomerID, PhoneDTO, AddressDTO)
CustomerService.Assign(CustomerID, SalesManagerID)
CustomerService.MakeDiscount(DiscountDTO)
These methods validate parameters, request domain objects and invoke domain object methods to apply business logic.
The problem is that it looks like huge code duplication, since WCF Service methods are almost (90%) identical to methods of domain layer with parameters, expressed in IDs and DTOs.
Is this method duplication always happening when WCF / SOA is used with DDD?
Is there any way to make this thin WCF Service layer build automatically from Domain Layer?
Any other ideas?
This is by design. With DDD, domain logic is separated from application logic. Thus, there is no code duplication, because the two layers have different responsibilities.
Code that potentially could be duplicated are the validation rules: They are usually used in the domain layer to enforce invariants, and in the service layer to perform input validation. If this is the case in your application, you should refactor your code to remove the duplication and make the validation rules reusable. See also this answer.
If the problem that your software solves is so simple that the above still feels like repetitive work, DDD is probably not the right approach.
Related
I am building a WCF service.
The Data Contract objects will be the exact same as the Business Objects.
Should I create Data Contracts in my WCF service or reference my BO Layer and use those Business Objects in my WCF Operations?
I would split them in different projects:
Foo.DataContracts
Foo.BusinessModels
Foo.Services
Reference BusinessModels and DataContracts in Services. Then map the model classes to contract classes using AutoMapper and vice versa. You can then later change your models without breaking your WCF clients, since they rely on the contracts.
If your business objects can be serialized without muddling the concerns of serialization in with the business logic, then I'd say go for it.
A better alternative though is to bring your business logic layer behind the Services layer and expose simple DTOs from the service that your view can bind to.
I wrote an article on this approach with WCF RIA Services that translates pretty well to standard WCF Web Services
I think in the same line of #valpolushkin though I have not used AutoMapper till now.
See my answer in WCF Message & Data Contract, DTO, domain model, and shared assemblies for an example where the use of Business Entities as Data Contract can cause breaking changes.
I think, it is a very bad practice to use Business Objects as DataContracts. The Service need to be autonomous. The service may be used by clients that has / has not got Lax Versioning.
Refer Service Versioning.
It is easy to mistakenly believe that adding a new member will not break existing clients. If you are unsure that all clients can handle lax versioning, the recommendation is to use the strict versioning guidelines and treat data contracts as immutable.
Also, refer MSDN - Service Layer Guidelines
Design transformation objects that translate between business entities and data contracts.
I have business layer and UI layer in separate projects within a same solution. What i need is ,connect this UI with business layer which coded in c#. UI created using MVC3 Razor.
What i should use as model in MVC application? am i need to create Service reference to business layer to generate some proxy?
then can i use those proxy as a model? please help me..
if you can provide me some tutorials
i tried this but no more idea with MVC :
http://www.dotnetfunda.com/articles/article816-understanding-the-basics-of-wcf-service-.aspx
Unless your project (or architect) demands that all methods of your app access a services layer, I would try and avoid using WCF unnecessarily (think of it - it means that all of your data between web server and back end goes over the wire, which has implications such as performance, serialization of data, and also potentially limits the lifespan of database connections and transactions, which can deprive such as lazy loading).
If you concur, the suggestion would be to ensure all accessible interfaces in your business layer are exposed on an interface, and then consume or inject the BLL interface directly into your controller.
You need to be careful about the word "Model" in MVC - ASP NET MVC encourages ViewModels, which are specific to the presentation tier and passed between Views and Controllers, as opposed to "Entities" which represent the more logical domain model as used by business logic and which can be tied to data persistence using an ORM such as EF or NHibernate. The MVC project template lumps everything which isn't View or Controller into "Model" which isn't necessary very helpful.
However, if you do choose to access your BLL via a WCF Services layer you still have some design decisions to make:
Choose whether you share the back end entities on the client side, or do you instead use proxied entities.
Choose whether you consume / inject the WCF service proxies directly in your controller, or do you create another facade layer (e.g. CAB calls these ServiceAgents). The latter would make sense if there are separate teams or vendors building the SOA side vs the Client side in order to accomodate changes to interfaces.
I am unsure where to place my business logic. I have a WCF service which exposes its methods to my client.
Should my business logic go in the service method
public User GetUser(int id)
{
//Retrieve the user from a repository and perform business logic
return user;
}
or should it be in a separate class where each WCF service method will in turn call the business layer methods.
public User GetUser(int id)
{
return _userLogic.GetUser(id);
}
My personal preference is to have WCF as a very thin layer on top of a separate business layer. The WCF layer does nothing more than make calls to the business layer, similar to what you have shown in option 2. This gives you some flexibility in the event that you want to have your business layer consumed by something other than WCF clients (for example, a WPF application calling your business layer directly rather than via WCF).
WCF services are already, by default, designed for reuse. I see no reason not to have some logic in your services, though keep in mind things like the Single Responsibility Principle so you don't end up with a service that does a dozen things.
Even then, if you end up parceling out your functionality into smaller classes, it's not a bad idea at all to host those classes as WCF services. You can then use them in-proc (via pipes) when needed or across machine boundaries (tcp) or even as web services. Create facades as needed to provide access to the functionality of your other, smaller services.
There's no real need to avoid putting any logic in WCF service classes.
I think that the decision depends on your business needs. WCF is a mechanism to transport data (objects) between server and client. If you like your businsess logic runs on server, you should let WCF exposes the object after running your business logic.
It should go in a separate set of classes. Your WCF layer should only contain logic that directly pertains to how the product of the service is delivered.
In your case, I see that you have a WCF method that returns a User (I assume this is a custom class) why have a separate method to return the UserID instead of populating that property as part of returning the User object?
For reuse/testability/maintenance/readability you should always put you BL in a separate layer.
Hi
we have used the WCF service in my project. In our application the following layers are exists,
UI (aspx file), and code behind.
(Customer.aspx)
UI entity Model (CustomerModel.cs)
which is properties of the customer
details.
UI layer calls the Business Façade class with the CustomerModel object.
In Business façade I have referenced the WCF service.
Convert the CustomerModel to CustomerContract.
Call the CustomerService from business façade.
In the service, I have convert CustomerContract into CustomerBO and call the CustomerBO class.
In the CustomerBO class,I have initialized the provider object and call the customer Provider class.
In Provider class, I have access the Database and send data from 8 to 1 layer.
I don't know which design pattern is using in our project. Can anybody help on this to identify design pattern.
Thanks
This is not about design pattern but about architecture. Your architecture itself is not bad but it is really complex so unless you are creating very big project this architecture can be overkill. Moreover your naming of different layers is not correct. What you call BusinessFacade is usually called ServiceAgent. BusinessFacade should be placed on service site and wrapped by WCF service. Usual responsibility of BusinessFacade is to aggregate several business operations into single calls = create less granular API which can be easily and effectively exposed for remote calls.
Is it possible to use DDD and a rich domain model if your application is like:
windows client (WPF)
windows service
And communication happens with WCF?
I'm used to have DTO's with only data state, and have business rules inside the Service layer, but everyone keeps telling me that I should have a rich domain model where data state and rules/methods are all in the objects themselves.
I'm just not sure if this rich domain model would apply to a system that has a UI and communicates via WCF to a service (like I presented above). In my case is it better to continue using an anemic domain model because of WCF? If not, could you please give an example on how to architecture it using a rich domain model, considering WCF, proxy, etc?
Thanks!
Generally speaking you serialize your domain objects for transmission across WCF as some simplified DTO anyway, and it's these that are consumed by your client application.
You can serialize user defined types and deserialize them in the client but for most applications this is unnecessary. As long as you don't need the 'rich' behaviour of your objects in your client (which you shouldn't with a good DDD anyway), it sounds to me like you are fine to use a rich design in your service layer and send simple DTOs across the wire.