I am developing one application in MVC4 with sybase as database. I am not using Enterprise library for database activity and not using any ORM tools like Entity Framework.
I want to implement Repository and Unit of work patern in this application for models. But on internet all application sample i found uses entity framework.
Please help me to achieve repository patern without entity framework.
Repository pattern is unrelated to ORM or the db you're using. You simply define an interface that works with your business objects (save/get) and implement it in DAL.
The Repository implementation will just use whatever you have to access the db (ado.net, a micro orm, full ORM), really it's just a class working with the db saving and restoring business objects. Nothing special, nothing magic.
Related
I recently stumbled upon ABP (previously Asp.Net BoilerPlate) as a framework to rebuild a web-app in a modular way. It's very interesting indeed, and come with a very wild bunch of basic elements like authentication, logging, security, multi-tenancy, settings and so on...
But, as far as I have understood it by now, ABP is "strongly coupled" with EF Core or Dapper, and I don't like to use ORM in my code, I have a more "database driven" approach and like to write queries myself.
So, the main question is: it's possible to use ABP WITHOUT using EFCore/Dapper? Or it's better to switch to other modular framework like OrchardCore or ExtCore?
EDIT: 11/11/2020 after #hikalkan reply.
Hi #hikalkan, thanks for your kind reply. Maybe I have to explain more what I want to achieve, so you can advise me better. My goal is to create a "pluggable" web-app, in which I can replace a module with another with same functionality but different details.
A little introduction: I have a "complex" web-app for HR departments of small-to-medium companies, many customers use it, and each one have its own copy installed in its premises. The app is composed by many functionality: personal data, contracts data, trainings data, shifts and so on. But each customer have slightly different modules, while the app itself is an old, monolithic one: it works, but I have to maintain different versions, almost one for each customer, very difficult and time consuming. Don't blame it on me, I have "inherited" the app and have to maintain and improve it that way.
But, finally, I can spend some time rebuild it from scratch, and I want it to be "modular", so that the main part (authentication, profiling, db interaction, theming, security, logging, etc...) stay stable & solid, shared among all installations, and each customer have a selection of module/plug-in to choose from. A bit like Wordpress, but better.
For example, let's say I have a simple module "contactSimple" for managing contacts (emails, phone numbers, pagers, and so on), each contact have a type and a value field in the database, very basic, and 90% of my customers are happy with it. But the remaining 10% want to add a note field, a flag "is main contact" or other minor changes. Now, what i want to do is: develop the "contactEnhanced" module as a separetad class library, with same interface and main functions of "contactSimple", compile it as a dll, simply change the dll in the web-app, update the database if needed to, reload the app and the new dll takes place, without altering any other component.
I was thinking to simply use dynamic reflection to obtain it, but then i found that reflection is not very suited, 'cause is slow and heavy on resources, so while surfing the web I find ABP.
Now, THE question: in your opinion, is ABP the framework/solution I was searching for? Please let me know!
ABP is designed to be database provider independent. It currently has two DB provider integration options: EF Core & MongoDB. That means ABP is not strongly coupled with the EF Core or Dapper: It works with MongoDB too. You set -d mongodb if you've created your solution with the ABP CLI.
So, the Framework itself has no relation to any database provider. But the pre-built modules have. For example, ABP provides an Identity module that has user and role management functions and needs to a database and includes some code to interact with the database. So it can't be db provider independent. All the pre-built modules provides EF Core & MongoDB integration packages.
If you want to use these modules (when you create a new application from the startup templates, some modules come pre-installed), you have to decide to use EF Core or MongoDB for the database operations of these modules.
When it comes to you own application code: You are free to use any approach, including ADO.NET with manual SQL queries. Just do it how you do in a regular application. If you want to isolate database queries, create your own repository classes. In this way, you don't see ORM in your code. But the modules still use EF Core or MongoDB.
Actually there a possibility to completely drop the EF Core references: Implement all the repositories needed by the pre-built modules yourself. Then they will work since they only depend on repository interfaces.
BTW; If you use OrchardCore, it uses YesSQL (Yes, YES SQL) as a core dependency and you can not change it because all the OrchardCore framework depends on it everywhere. Also, OrchardCore is UI dependent: It uses aspnet core MVC / Razor Pages UI while the ABP Framework is UI independent and provides 3 built-in options: Angular, MVC and Blazor.
Edit: After edit of the question
The story you've explained is one of the goals of the ABP Framework. ABP is highly modular and also extensible. We built all the modules to be extensible. For example, the module entity extension system allows you to add new properties to existing entities of a module (the module is used as a NuGet package) without touching its source code. You can override the server side logic of the module.
But modularity is hard in general. I mean the module also should be designed so extensible/replaceable. If you want to declare some interfaces for a module, so the module can be completely replaceable, you have a lot of restrictions. For example, you can not write SQL join queries to tables of that module (because the replacement module can use a different table structure).
However, if the customizations will be lighter, you can follow the ABP Framework's module design to make your module extensible/customizable. See https://docs.abp.io/en/abp/latest/Customizing-Application-Modules-Guide and https://docs.abp.io/en/commercial/latest/guides/customizing-modules (commercial docs will be moved to the open source side since they are available as open source now). BTW, ABP supports to load modules as dlls from a folder. It reads dlls and initializes modules on application initialization.
I can only explains what ABP offers. I can't make suggestion, unfortunately. Because a real life project is complex and I can't predict all the problems & requirements you will have in the future :)
My recently created package rely on repository interfaces. One of the choices for a source data is database and Doctrine ORM. As database is just one of possible choices, I do not want to integrate the whole Doctrine ORM package, but to create an appropriate adapter that just depends on Doctrine\ORM\EntityManagerInterface. The question is how can I "composer require" partially from Doctrine ORM ? I'd like to add, that I could not have found any separate package with the Doctrine ORM EntityManagerInterface.
Thanks in advance.
There is no way to just require a single class/interface from a package. What you could do instead is require doctrine/persistence. This library provides persistence interfaces which are then used by Doctrine ORM/ODM. Instead of relying on the EntityManagerInterface you would then rely on the ObjectManager-interface.
If you want to neither rely on doctrine/orm nor doctrine/persistence then you should use require-dev and suggests to allow for using those dependencies during development, e.g. for writing tests against the Doctrine EntityManager, and to inform users of your library which persistence libraries you explicitly support and require those as well.
You could also create your own EntityManagerInterface and then provide a second package for integration with different providers which then implement that interface in an adapter. So instead of pulling doctrine/orm into your library, you expose your interface and provide custom libraries for data providers like doctrine/orm. This way you inverse the dependency requirement, but unfortunately you will have more maintenance work. You can look at projects like php-http/httplug and the corresponding php-http/*-client packages for inspiration. They have a similar approach when it comes to integrating multiple clients (guzzle, curl, ...) and provide a common abstraction on top of them.
I'm writing an application that manages something like Drupal's nodes. I'm planning on using the app in various content management systems / applications (Concrete5, Wordpress, custom Zend & Yii applications, etc...).
Since I'm using it in so many different places, I have to package an ORM with the app (ie I can't use Conrete5's or Yii's ORM, etc...). I love Doctrine 2, but am concerned that this is too 'big' of an orm to be packaged with my app.
It get's messy, for example, if I'm incorporating this app with a Zend application which is running Doctrine 2. I don't want two 'instances' of Doctrine running in the same app. Is this a warranted concern?
Question: Is Doctrine 2 too 'big' for this project? If so, what would be a good alternative ORM?
If you are going to use your application as an extension for other CMSes and/or frameworks,you should definitley use an ORM for the following reasons which comes to my mind:
1.CMS database installations are different.some use mysql some use oracle ,etc and you will have to create your own adapters or
2.Use CMS's native database abstraction layers.So you will have to rerwite your own model for every cms plugin you are gonna make.
3.Doctrine can do many big jobs but using doctrine is rather easy.doctrine is not resources intensive.
4.using more than one instance of doctrine will not be a problem as far as i know.
5.however doctrine2 requires minimum installation of PHP 5.3 and some shared servers might have older versions of php which this problem will be resolved while time passes and 5.2 becomes obsolete.
However in some CMSes more than one connection will made for your extension to work.(one for the CMS'S native database queries and one for your doctrine query.)
Way 1: work with different ORM's via adapters
(+) better integration with frameworks
(-) a lot of work to implement adapters
(-) loss of flexibility (limited by your adapters interface)
Way 2 (my choice): Use PDO with FETCH_CLASS, it's comfortable enough (you can fetch data to instances of your classes). Most of modern ORM's on PHP works through PDO, so integration must be easy.
Also about Doctrine 2 & Yii -- I tested this combination, works fine.
I am facing a weird problem with Fluent, NHibernate and Spring.net. My project is an ASP.NET MVC 2.0 (.net 4.0) project.
I created my project based on Spring.net Nhibnernate Northwind project. I am also using Fluent code based mappings as suggested on this page http://blog.bennymichielsen.be/2009/01/04/using-fluent-nhibernate-in-spring-net.
When I apply tx:attribute-driven to my spring context xml file, it breaks the application. The LocalSessionFactoryObject is not injected in my DAOs. I tried pulling the SessionFactory manually from the context, the app works but the transactions are not rolled back.
If I remove the tx:attribute-driven attribute, the app works but of course the transactions are not rolled back. The logs dont show any errors. Since the app is working without the attribute, I am guessing most of my configuration should be ok.
Has anyone used a combination of Fluent, Nhibernate and Spring.net successfully with Transactions?
I can provide more details about my setup if necessary.
I figured it out myself. In case someone else is having problems with Transactions or any spring supplied features related to AOP, please make sure you are programming against Interfaces and not concrete classes. Somehow I was missing this. If you use concrete classes, your code will not be able to use the special proxies created by Spring and the features like TX management will not be available.
#Ketan.
If your domain entities are equals to Database tables, you can use the Automapping inside Nhibernate Fluent project... this is the automapped classes... easy to use. Check this out: https://github.com/FluentNHibernate/fluent-nhibernate/wiki/Auto-mapping
I would basically like to know things such as:
Advantages/disadvantages between the two?
Similarities/differences between the two frameworks?
How are they similar/different architecturally?
How much boilerplate code is needed to use each?
Can the Entity Framework be used efficiently outside of Visual Studio compared to NHibernate? Is the Entity Framework more efficient than NHibernate when used with Visual Studio?
Note: This question refers to the Entity Framework 2 (currently still in development).
Disclaimer: This post is based on my current knowledge of what the next version of Entity Framework will be like. That might be inaccurate or it might change until the next version is actually relased.
General Approach:
The main approach of Entity Framework (EF) is using their graphical designer tool to create an Entity Data Model and to generate domain classes as well as mapping from that model. There is support for other approaches as well, but that way of working will probably always be the main one.
NHibernate (NH) is a text based tool which requires the user to write all the domain classes and mapping manually, if you don't turn to third party software for code generation, such as MyGeneration of CodeSmith, or additional convention over configuration support, such as Fluent NHibernate.
Code Generation:
Code generation is a major part of standard EF usage, either by using their graphical designer tool or by using their command line tools. The availability of both GUI and command line tools is a plus since makes EF easy to get started with as well as allowing for more advanced usage that can be automated, for example in a build process.
Code generation is not supported by NHibernate, except for the schema generation stuff if you want to count that as code gen. You can get code generation if you turn to third party software though.
Database Schema Generation:
EF will add support for model first development, by allowing the user to generate a schema from an Entity Data Model. NHibernate has had schema generation support for a long time. The difference here is how you create your "model", as mentioned earlier.
LINQ:
EF will have improved their whacky LINQ implementation from v1 and NH have now reached version 1.0 of LINQ to NH, so there should not be any major differences between the two in that regard.
POCO:
EF will add better support for the Domain Driven Design approach and the use of domain classes that are separated from the data access layer. However, since POCO is not the main use case of EF I can't really see how their POCO support could ever reach the level of NHibernate. The POCO support in EF is still young, and to me it feels more like that it is a bonus if you are a POCO/DDD supporter and you find yourself working on EF for some reason.
The entire NHibernate framework is build for POCO development, by DDD people, and they have reached version 2.1 as well as taking advantage of all the work put into Hibernate on the Java side. NHibernate will probably remain the no 1 choice for the DDD/POCO/ALT.NET crowd for quite some time.
Lazy Loading:
The next version of EF will include support for automatic lazy loading. Automatic lazy loading has been an important part of NHibernate for a long time.
Learning Curve:
Both frameworks are complex and powerful, and hence take a long time to master. But EF is quite beginner friendly since it is integrated into Visual Studio, with its graphical designer tool, and since it can generate a lot of stuff for you without you having to know just about anything about the framework. However, if you want to dig deeper into EF and really learn the framework, you should be prepared to spend quite a lot of time using it.
NHibernate has a notorious learning curve, but some recent improvements have reduced it a bit. Now that LINQ to NH is at v1.0 the query syntax will be easier to understand for developers new to NH, and the Fluent NHibernate project is improving the mapping experience, and even working on automatic mapping, which is getting better and better all the time.