I have SQL Server database and would like to use LINQ to Entities and wrap it with WCF layer and expose it to client. (typical N-Tier architecture). ALso would like to have Persistence ignorant option and also would like to have an option ignore certain fields (sensitive information) in database from serializing it to client.
So what would be best approach for using Entity Framework with Persistence Ignorance, Self Tracking with WCF Support. I could find T4 template with either Self Tracking or Persistence Ignorant.. But everything bundled as single package.
Any help in this would be greatly appreciated.
STEs don't allow any projections - you must expose your entities in their exact form. If you want to hide some fields you must abandon STEs and create your own DTOs (data transfer objects) exposing only subset of your entities data. Once you use DTOs you must manually handle all change tracking.
Related
As title says:
Should the query side of CQRS applications call the database direcly in the controllers/handlers and skip application services, domains and repositories?
What if the query logic is complex and/or I also need to publish an event (related to the read operation) to a message broker? In what layer would that logic fit?
The Query side will only contain the methods for getting data, so it can/should be really simple. The domain model from the command side is definitely not part of the query side. The queries are separate from the model we have in our domain. An abstraction on top of your persistence is not required too.
Simple query logic would make your life easier. The secret sauce of CQRS is polyglot persistence. You may maintain multiple denormalized representations of your data, also known as a materialized views, which are tailored to your query needs.You can have multiple projections on your data on different databases depending on your query needs. If you do that, the query side tends to become simple
e.g. if you have a projection of something that is an entity in your domain like a customer then you can persist it in Mongo and query it by id - really simple and performant, if you have some report with multiple orders you can persist those in a relational database and do sql queries - simple and performant. This way you would end up with GET queries that do database queries and return the read models without any additional mapping.
Having said that, I would like to state that this a typical use case, but your read models can also be slightly different queries on the same table of a db. This would make the query a bit more complex, but might be good enough too.
I also don't think that you should publish an event from the query side. What would that event be?
What i mean by the title is: we have a system with different submodules, each with their own (MVC web) application. I thought about creating a REST service that accesses the database and gives data to the applications so no application themselves can access a database directly. The API calls on all the methods that access the database and an application chooses, which to use etc. Basically the web application's models aren't themselves mapped to any database entities which is commonly done in MVC applications (like in ASP.net with entityframework).
Why i thought about this idea in the first place is because i couldn't figure out how to map models to database tables without having to map to all of the tables and their attributes (switching some off for some applications, we're using Phalcon) and have hundreds of unused models in each application. How bad of an idea is creating a REST API for this?
If each application will access the same database you will have to maintain a lot of boilerplate model code (sql/orm). In case of some changes in database you'll have to propagate changes to every application.
In terms of maintenance it is better to expose business operations through web service which will be the only point of contact with database.
In case of web service changes inside database are not visible in applications
On the other hand without web service in front each change to database requires change in each application.
I'm trying to develop a .net4 application using c#, wcf and entity framework. My first idea was to pass the EF generated objects through wcf (first with the default entity objects, then with the POCO entities), but I soon got several connection problems (connection is closed) due to non serializable objects in the generated entities. I ended up writing several data-only classes to host the data queried with EF, but now I miss the role of the EF with WCF. I guess I'm doing something wrong, so how do you send data through wcf using EF? What is the point of EF? Wouldn't it be easier to write stored procs and standard ado.net...?
Entity Framework is just a data access technology. You can create a data access layer which talks to your database and return the required data using Entity framework and then plug that to your WCF service so that your WCF service will get the data. You can use the same data access layer with any other consumers ( a Silver light application, A Windows form project or an MVC application). The advantage of using Entity framework is that it will load the data to your domain objects (your POCO classes) so that you do not need to do it manually yourself. In the case of Stored proc, you need to execute the stored proc, Iterate thru the DataReader/ DataTable the fill your objects. For this you have to write code. If you use Entity framework, EF does this for you so you can save some dev time.
You should clearly logically seperate your project so that there will be a data access and a consumer which consumes the Data Acccess layer( your WCF service).
In this moment, I have two web applications(one application is an MVC2 application for the management of my project and the second is an application with web services). Both applications have to deal with the database and have Nhibernate for querying the database. Is this a good pattern?, if not what can i do?
Edit 1
Both applications can write to the database. I have a dll project that handle the database transactions and have de nhibernate instance named "Repositorio". Nevertheless, each application will have a different instance of Repositorio.dll so there is going to be multiple threats to the database, what do i have to do to make both application use the same instance of Repositorio.dll?
The answer depends on whether or not both applications can write to the database.
If one is read-only, I'd say you're safe.
I not, I'd argue that a service-oriented approach would recommend creating a service that provided an interface for both applications and was the sole owner of the database.
"service-oriented" does not mean that the service has to be a distributed component (e.g., SOAP or REST or RPC). If you encapsulate the database access in a component with a well-defined interface you can choose to share the component as a DLL in both applications. Only make it a distributed component if that makes sense for both applications.
That sounds perfectly fine to me even if both applications write to the database. I would simply recommend you create a third project as a class library with all your nHibernate related stuff to avoid writing any redundant code in both projects.
I'm getting data where the database is hidden behind a WCF service.
Is it possible to use Entity Framework in a scenario where I have custom objects coming from a web service?
(No access to the external database, and no current plans for insert/update/delete logic)
Starting with an empty EF model and adding an entity I get this error on compile:
No mapping specified for instances of the EntitySet and AssociationSet in the EntityContainer ..
Is it possible to make an entity this way, and fill it with data received from an object?
(In this case a WCF, but could also be a predefined model class/xml data)
If the web service retured a Customer object I could do something like this with a dataset:
Make an unbound table and do a loop through the customer properties adding them to a temp row, add it with tbl_Customer.Addtbl_CustomerRow(customerRow) to get my view filled.
thanks, nakori
Entities are object representation of your DB entries (see Object-Relationnal Mapping; ORMs). Given Employee and SalesOrder, two hypothetical tables in a DB :
Entity: entities are instances of Entity Types (e.g. Employee, SalesOrder), which are richly structured records with a key. Entities are grouped in Entity-Sets.
Taken from the Modeling Data at the Conceptual Level of Abstraction: The Entity Data Model section of The ADO.NET Entity Framework Overview. Perhaps it is also a good read to start using the EF.
As for comm through WCF, it is kindof supported, such that entities are fully serializable/deserializable. You may also want to know that you can generate entities from an existing DB, theres a wizard and everything.