I originally wanted to find out how to access the Doctrine 2's Entity Manager from within Entity Classes. But I saw another question Using EntityManager inside Doctrine 2.0 entities, and learnt that I should be using a service class. I wonder where should I put in a Zend Framework Application? Also is it also called a DAO (Data Access Object)? I am thinking of naming it DAO instead of Service as Service sounds alot like something for external sites to use (like Web Service)?
I am thinking something like Application_Models_DAO_User?
Service classes are part of the autoloader mapping. Like Application_Model_Something can be found in application/models, it's the same for services.
An application service Application_Service_Something should be located at: application/services/Something.php
When you use service classes inside modules, for example Blog_Service_Something they need to be located at: application/modules/blog/services/Something.php
I think classes like entity managers shouldn't be part of your controllers nor your models, but located in service classes.
Related
I'm new to .NET Core and Blazor, with mostly WebForms and MVC experience.
All the Blazor documentation and tutorials I've found use a separate API project and access data through HttpClient and Json serialization/deserialization. I see why this would be necessary for client-side Blazor using WebAssembly, but for Server-Side Blazor using SignalR what's the best way to access the database directly from the components' .razor files using an Entity Framework DbContext?
For example, in an MVC controller you can just do something like:
private ApplicationDbContext context = new ApplicationDbContext();
and then query the data by doing something like:
var things = context.Things.Where(t => t.ThingAttributes == something);
Is there an approach that is this clean and efficient when working with components in server-side Blazor?
Sorry for the broad nature of this question, feel free to point me to blogs, docs, or tutorials I should have already read. Thanks!
What you call a controller should be turned into a service class, that retrieves data from the database, and pass it to the calling methods. You should add this service to the DI container in the Startup class. To use this service in your components you should inject it like this:
#inject DataService myDataService
I think that the Blazor templates come with sample how to define such a service and use it in your components.
Here's a link to a sample by the Blazor team how to create a service and how to use it in your components. The service doesn't use Entity Framework, but this is something really minor I'm sure you'll cope with.
I created a WCF service in charge of exposing my database's data since I don't want the database to be directly accessed by my application (for security reasons) and i need to be able to share data with third-party applications.
My solution is structured this way: WPF application -> WCFService library -> DataAccessLayer library. (Arrows define assembly dependencies 'depends on')
To implement the WCF service I considered to simply return detached EntityFramework objects from the service BUT it forces the main application to have a dependency on the DataAccessLayer library.
The only way i can get around that is generating POCO objects and use them to send them over the wire, but now i have to map values back and forth EntityFramework.
At the moment i'm generating POCOs dynamically via a T4 template and I'm using AutoMapper to map values back and forth EntityFramework.
The Wcf service will just have to implement the repository pattern to expose data.
Is this a good solution? Are there any other option?
Is there any shortcoming i should be aware of?
Depending on your constraints, I would have to agree with this solution.
I created an almost identical solution, although our motivations were slightly different. Our client was Delphi Win32, and at the time didn't have good support for JSON, so we had to use SOAP.
The client also didn't support nullable primitives, so the POCOs removed all unsupported types, and performed other changes to ensure interoperability, then we used Automapper custom mappings to handle the two way conversions.
All the WCF services (contracts and implementations) where also generated by T4 templates, using a generic repository. With T4 templates, I was able to generate a separate WCF service per table for CRUD operations, and then manually created WCF services that were business specific.
Finally, I was also able to used T4 templates to generate the Delphi repositories that interacted with the SOAP services.
Or
You could just as easily move the POCOs (and code generation) to a separate project, change your DataAccessLayer library to reference the POCOs library and only contain the Db context made up of DbSets of your POCOs, and Data access logic but no entities (which are now POCOs). Your clients will not need to have a dependency on the DataAccessLayer library.
So... a good solution, depending on your constraints.
I am looking for some best practice advice with regards to building a self contained service, that is a DLL with all of the domain logic and data layer. I would like to use an off the self CMS, such as orchard, then talk to the service to carry out CRUD operations. The service should have it's own IOC, and ORM, in this case I am using Ninject and Entity Framework. In this design I will have a separate database than the CMS, and can port it to other CMS systems when required.
The CMS should start the service and pass it a connection string or file name. If I use orchard it has different ORM, and IOC frameworks, so this leads me to wanting to keep Ninject and Entity Framework inside the service.
I have setup an experiment where the DbConext and domain are in the service DLL, and I call it from a console app. This only works if I have entity framework referenced in the console application, even though I don't use it in that dll. Here is the error message when EF is not referenced by the console app.
No Entity Framework provider found for 'System.Data.SqlClient' ADO.NET provider.
Why is this and how best to solve my design problem?
If your library (DLL) depends on Entity Framework, it's perfectly normal that you need to reference both in your application (whether it's console, web or whatever else). You always need to reference all dependencies.
Wiring your custom library with Orchard would be fairy simple. The only thing you'd need to do on Orchard side would be to register the services coming from your library with Autofac, in order to have them available for dependency injection. This post describes a similar scenario to yours.
Please bear in mind that using multiple database connections is a bit troublesome in Orchard <= 1.6, because of the usage of TransactionScope - you need to run all your custom database code in a suppressed scope, otherwise you'd have transaction errors and/or MSDTC-related problems. It will be a non-issue since Orchard 1.7 which is going to arrive in about a week. I'd strongly recommend waiting for the new version. You can also fetch the pre-release code from 1.x branch.
I am about to start work on a ASP.Net MVC 4 web application using Entity Framework Code First. Because the database already exists I am using Code First's ability to perform Reverse Engineering in order to generate my domain classes.
I wish then to place these domain classes into a separate project of their own within my solution in order to keep them persistence ignorant. However, when I run the tool to reverse engineer my database (using Entity Framework Power Tools), I find that the domain classes are created, but also created is a folder called Mapping containing a mapping class for each domain class which then uses Fluent APIs to map the table properties. This is all good.
But, what I have also found, is that the mapping classes rely on a reference to the Entity Framework and I was just wondering is this thought to be poor practice? Usually when I create POCO classes, they are completely persistence ignorant, ie, there has been no reference to Entity Framework in that project at all.
Your thoughts?
Thanks.
You can keep your POCO classes in one project, while mapping stays in another project. Just add a reference to the project where POCO classes are located. Another approach is to create a data access layer and move mappings over there. That way you have three projects. Your main MVC project, your model project and data access layer that contains mappings and a reference to EntityFramework.
For example, your solution could be something like this:
1. Web User Interface (MVC)
2. Business layer
3. Unit of Work/Repository
4. Data access layer (Mapping from EF Reverse Engineering)
All four projects have access to the fifth project, Domain Model (Models from EF Reverse Engineering). Your 1 communicates with 2, 2 communicates with 3 and 3 communicates with 4. All four of these have a reference to Domain Model so you don't have to perform any type of domain model conversion between the layers.
By the way, I ignored service layer, but if you have web services or REST, you could fit it in another project, but let's not get into too many details.
Our project manager has asked us to refactor an app that was using the Repository Pattern (it was done using Nerddinner as example) to now use a service Layer.
My problem now is that Im not sure how to Update a Model cause the UpdateModel method is supposed to be used in the controller... whats a recomended approach to updating a model using repository pattern along with a service layer??
please help
I would suggest you 'hide' your current Repository Pattern inside your service layer. Data access code should not be visible to the clients of the service.
You can implement a collection of DTOs that will be returned from service layer or accepted as parameters. Those objects can be just POCOs to hold the data in a database-agnostic way.
DTOs are usually accompanied by Adapters for translation to/from your data access classes (that represent tables). This approach allows you to change database schema without changing service layer interface.
You can treat those DTOs as models in MVC, if your project is simple and data for your views matches the service layer DTOs. You can also define your models in MVC project and let controller or another set of adapters translate models into DTOs.
My preferred design includes model that are declared in MVC (Models folder) that work with strongly-typed views. UpdateModel method then works with those classes. Next controller or ModelAdapter creates an instances of Service Layer DTOs and passes them to services. DTO adapters inside services are then responsible to populate data access classes from repository pattern.