I have a wcf service which has a data contract say
1. Wcf service which has a data contract class called Rundata
2. Client WPF application which has multiple below listed projects under one solution
- wcfservice accessor
. - data analyser
. - data displayer
Now I made a service references in "wcfservice accessor" and I received the rundata object from the wcf service. Now my question is :
1. How can I make the "data analyser" and "data displayer" project to understand this rundata object since only "wcfservice accessor" alone has the service reference.
if your architecture is not allowing to 'see' the classes generated in the service reference. usually you need DTO class, DTO stands for "data transformation object" or "data transport object" it matters the case. So in the "data analyser" project is your business logic it need to have a reference to "wcfservice accessor" and the "data displayer" have a reference to "data analyser". So from "data analyser" to "data displayer" you can use so called DTO object.
Related
So far i understand that i will have no more need to define an #version field in my entitites and no more need to use an entity locator. And for value proxies i will have to usenormal editors. Any other diffrences, advantages, disadvantages? What about in the context of using request factory in conjunction with spring
The main difference is that with EntityProxy, the client can send a diff of changes rather than the entire object graph. This is made possible because EntityProxys have an identity, so the server can fetch the identity from the datastore and then apply the diff/patch sent from the client, and only then the entity will be passed to your service methods.
With ValueProxy you basically have an equivalent of GWT-RPC: the object is reconstructed from scratch on the server, and not associated with your datastore (in the case of JPA for instance, it's not attached to the session). Depending on your datastore API, this can make things more complex to handle in your service methods.
Other than that, you'll also lose the EntityProxyChange events.
I am trying to implement the DDD so I have created the following classes
- User [the domain model]
- UserRepository [a central factory to manage the object(s)]
- UserMapper + UserDbTable [A Mapper to map application functionality and provide the CRUD implementation]
My first question is that when a model needs to communicate with the persistent layer should it contact the Repository or the mapper? Personally I am thinking that it should ask the repository which will contact the mapper and provide the required functionality.
Now my second concern is that there should be only one repository for all the objects of same class, so that means I will be creating a singleton. But if my application has lots of domain models (lets say 20), then there will be 20 singletons. And it don't feel right. The other option is to use DI (dependency injection) but the framework I am using (Zend Framework 1.11) has no support for DIC.
My third
UserRepository [a central factory to manage the object(s)]
In DDD Repository is not a Factory. Repository is responsible for middle and end of life of the domain object. Factory is responsible for beginning. Conceptually, persisting and restoring happens to the domain object in its middle life.
UserMapper + UserDbTable [A Mapper to map application functionality and provide the CRUD implementation]
These classes do not belong to a domain layer, this is data access. They would all be encapsulated by repository implementation (or would not exist at all if you use ORM).
My first question is that when a model needs to communicate with the
persistent layer should it contact the Repository or the mapper?
Personally I am thinking that it should ask the repository which will
contact the mapper and provide the required functionality.
Model does not need to communicate with persistence layer. In fact you should try to make your model as persistence-agnostic as possible. From the perspective of your domain model, Repository is just an interface. The implementation of this interface belongs to a different layer - data access. The implementation is injected later, somewhere in your Application layer. Application layer is aware of persistence and transactions. This is where you can implement Unit Of Work pattern (that also does not belong to domain layer).
Now my second concern is that there should be only one repository for all the objects of same class, so that means I will be creating a singleton. But if my application has lots of domain models (lets say 20), then there will be 20 singletons.
First of all you can have more than one Repository for a given domain object. This is what happens most of the time anyway because you want to avoid 'method explosion' on your Repository interface. Secondly singleton Repository is a bad idea because it would couple all consumers to a single implementation which, among other things, would make unit testing hard. Thirdly, there is nothing wrong with having 20 or more Repositories, in fact the more focused classes you have the better, see SRP.
UPDATE:
I think that you are confusing regular Factory pattern and DDD Factory. In DDD terms, when the object is restored from the database it already exists conceptually (even though it is a new object in memory). So it is a responsibility of the Repository to persist and restore it. DDD Factory comes into play when the complex domain object begins its life - whether it would be a long lived object (saved in db) or not.
Answering your second question. The ZF1 way would be to create a singleton per object class. You could have a factory/registry that creates these for you and returns the previously created one when you ask for an already created one. Alternatively, if you are using PHP 5.3, use a DI container such as Pimple or Zend\Di.
When I try to ask a service - I get an exception
Unable to load metadata for return type
'System.Linq.IQueryable'
Inet says that service can not find model files. But I use code-first, and have no such files.
I use Microsoft.Data.Services.
You can say that my connection string is wrong.
But when I try to init myDbContext, my database is created without tables.
No breakpoints after creation context have been hit.
What can I do???
You may be missing datamember attributes in fields and datacontract attribute in class.
It is best to have some light class between your db and wcf ,so that you can add special attributes or create complex entities to use in wcf endpoints.
Just info if you are missing something about EF Code First & WCF Data Service.
There are two assemblies for creating and consuming WCF Data Services
in the .NET Framework 4: System.Data.Services.dll and
System.Data.Services.Client.dll. If you try to use these with a
DbContext and Code First classes, they won’t work out of the box. The
issue is with DbContext, not Code First. DbContext didn’t exist when
those assemblies were built, so they don’t understand it.
Resolution is either use ObjectContext (DbConext use ObjectcContext under the cover)
[OR]
Use March 2011 CTP that contained fixed-up assemblies (Microsoft.Data.Services.dll and Microsoft.Data.Services.Client.dll) that know how to work with the DbContext.
Checkout msdn article for details:
http://msdn.microsoft.com/en-us/magazine/hh852588.aspx
In the context of ASP.Net MVC 2.0, can anybody please explain why do we need to use DTO (Data Transfer Object) if there can already be Models? I have seen an example where a web service returns DTO to asp.net and then it is converted to Model using some factory class. This web service talks to database and returns data in the form of DTO.
In my previous projects, I used to communicate to DB using Data context and repository, which used to return model object to my controller. Then I used to pass this model to the corresponding view. Isn't this simpler? I cannot find out the exact use of DTO pattren.
Models represent the logical data model that your views are coded against. This may or may not map 1:1 with the source(s) of the data. In a situation where Model == DTO, I agree, the DTO is somewhat redundant.
In most situations where I've used MVC, it's been pretty rare to have a single source of data, or lack the desire to separate the logical view from the physical sources. For example I often make multiple service and database calls to build single logical model.
I've created an Entity Data Model and imported several stored procedures as Function Imports. I'm exposing the EDM through ADO.NET Data Services (ANDS). Does ANDS automatically expose the functions through its REST API, or do I need to manually add operations to the service?
You will need to expose the sproc through a ServiceOperation. From what I can tell, all mapping to a FunctionImport does is make it usable within the service via CurrentDataSource. Think of it as only a link between the concept and store.