I'm required to create a bit of software for a company, to illustrate my code use. I'm using .NET CORE Web App MVC and I believe it requires me to use a database but I would need to upload my code on GitHub for them to inspect and run but obviously wouldn't read the database from my machine. What are the alternatives? Can a fake DB be created within the project for instance? Or is there something else I could do that doesn't involve Azure?
I tried scaffolding a DBContext from a controller but it requires a connection of a database
Have you considered mocking your data connection? It is the same thing you would do if you were unit testing your application. You would not want to connect directly to your database; instead, you would create a mock connection and return the data yourself.
You have multiple choices here. You can use a Mock framework like Moq, FakeItEasy, JustMock, and NSubstitute. Otherwise, you can roll your own.
Related
Does anybody know whether there is a way to use default OpenIddict storage functionality in a project which doesn't use Entity Framework and has not empty DB?
I'm trying to integrate Openiddict server to my Web App. The app has a DB, but communication with it is done using classic ADO.Net. I tried to find a similar example in the openiddict-samples repository but unfortunately without result.
I know that I can implement my own TokenStore, ApplicationStore etc. and register them via extensions for OpenIddictCoreBuilder but I'd like to use the default implementations in case it's possible to do that with not empty DB and without EF or with EF but for Openiddict functionality only. My DB is quite big and it's not an easy task to migrate it to EF.
I tried to use code from existing examples but those didn't work in my case. What I found out is that it works with empty DB only, otherwise OpenIddict tables are not created.
So I would very appreciate for any advice or link to example which I should investigate more carefully. So to say make OpenIddict to create its tables automatically, under the hood.
P.S.: I of course can copy those tables from examples and include scripts for their creation in my app, but I'd like to use the built-in functionality as much as possible.
OpenIddict version: 3.1.1
It seems that for now there is no a built-in functionality to achieve the wanted behavior. The only way is to create own Stores and StoreResolvers for OpenIddict and migrate tables creation to any suitable solution: a set of sql scripts, some kind of migration (e.g. FluentMigration), etc.
For now OpenIddict out of the box supports EF and Mongo only. This implementations can be considered as examples for implementation of Stores and StoreResolvers.
Our team (QA) is facing the following problem:
We have a database that is accessed only by our Core application which is a WCF services app. Our client applications are using the Core to access the database.
At some point we were provided with a new Version of our Core application and of our Database. The Dev department also gave us a sql script which is altering a big part of our database Core data. The core data are used by the Core Application to describe the Logic of our system, so every change on that data may have affects on any of our client application's functionality.
My questions are:
Should we test all of our applications again (even if they are
already fully tested) or is there is a more efficient way to test the
SQL script?
Is there a testing technique/tool for data integrity/migration testing?
I am looking for a quick validity/integrity testing of the database after running a migration script. That will prevent us losing time by testing it through the applications. If the validity/integrity testing is successful then we can test the apps.
There are unit testing frameworks available for T-SQL. The TSQLUnit project is one such framework. You can use it to set up automated testing, just like you would in the applications.
as #Tim Lentine already posted, I would recomend testing the full application. As you commented, the new sql script your team received has made important changes on the core of your database development, according to your description, both on the structure and the data itself. So in order to be sure that everything is still on one piece I would preferably do a full application test. As for a tool or technique I can recomend the new RedGate (no, I do not work for them) addon on the SSMS called "SQL Test". It uses the unit testing open source tSQLt for its purposes. It only has the drawback that someone will need to first learn how to work with tSQLt but is prettu straightforward.
From the description you gave:
We have a database that is accessed only by our Core application ...
we were provided with a new Version of our Core application and of
our Database ...
tells me it is not your team's responsibility to test the database in isolation, but you can test the Core service from your client's perspective and therefore assume the database is correct.
Treat the Core application and the database as a black box and test using Unit Tests. These test should not require you to go poking around in the database as for all intents and purposes any application using your Core application doesn't know, nor should care, that the information is actually stored in to a database. You development team could decide in 6 months they are going to store the data in the Cloud in which case all your database test will be broken.
If you do have to look in the database to check data has been stored correctly then there is a problem with your Core service's interface as any data you put in should be retrievable via the same interface (I just know someone is going to comment that their app does store data which cannot be read back but without a more detailed description of your app it's easier to generalise).
Back in the real world I am assuming you are part of the QA team and unless the database developers are doing some testing (they are, aren't they?) you are more than likely going to have to validate the database changes.
To the end you may be interested to read a question I posted on the DBA Stack Exchage site about performing a data comparison between two different schemas. Spoiler: there's no easy answer.
show below links :
http://www.simple-talk.com/sql/t-sql-programming/sql-server-unit-testing-with-tsqlt/
http://www.red-gate.com/products/sql-development/sql-test/
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.
Im interested to find out what techniques developers are using to connect to a Windows Azure instance running in the cloud?
From what i understand it is very similar to SQL Server with two of the key differences being Multiple Active Recordsets are not supported and idle/long running connections are automatically terminated by azure. For this microsoft suggest incorporating retry logic in your application to detect a closed connection and then attempt to complete the interrupted action. Does any one have example code that they are currently using on this?
To build out the data layer i was looking at various ORMs. Since im going to be accessing azure from windows azure (ie seperate boxes) to me it would seem key that any ORM mapper would need to support asynchronous methods so as not to block any windows azure instances.
Any suggestions as to which ORM mapper to use, or comments on what you are currently using
I have successfully used NHibernate with Azure and we are in the process of building a commercial app on top of NHibernate. The only problem that I had was with the connection pools when running locally and connecting to SQL Azure in the cloud - which was fixed when turning connection pooling off.
You may find similar problems with other ORM's... SQL Azure is less patient (for obvious reasons) than most people are used to. Connections timeout quicker, recycle sooner and so on.
Test first!
Here's one specifically designed for Azure:
"Telerik recently announced the
availability of Open Access, the first
ORM that works seamlessly with SQL
Azure relational databases in the
Windows Azure cloud."
And a few commenters at the Azure User Group recommend LLBLGen and Entity Framework.
I've been using Entity Framework - runs without any problems, just a different connection string.
What you do have to think about is your connection strategy, and how efficient your queries are. I've got method that's easy to write in EF - I've got a new record that could be duplicated, so I check if it's there, and if not, add it.
EF makes it really easy to do this, as if you're just accessing a local collection. BUT ... if you're paying for your dB access because it's in Azure and not on your local network, hmm, maybe there's a better (aka cheaper) way of doing that
According to Ayende, NHibernate "just works" with SQL Azure.
We have been using NHibernate without any customization on Azure (indeed, it just works), you can check Lokad.Translate as an open source example of such use.
I am developing a framework for various in-house CRUD apps. I've considered several MS technologies (WPF, Access, WinForms, ASP.NET) and have settled on ASP.NET MVC with HTA+Jquery for the client. My reason for doing so is that I need a way to write and deploy quick one-off GUI apps as well as maintaining more robust apps that are expected to have a long life time.
Firstly, I would appreciate some thoughts on the relative merits of using ADODB on the client side versus ADO.NET on the server side. I'm leaning towards ADODB since I'll have client side access to the SQL Server (I've already written a js library that handles interacting with ADODB). However, I can see how developing a RESTful service may eventually be useful.
Secondly, I need to incorporate reporting capability into the system. I can use SQL Server reporting services or crystal reports but the users have grown accustomed to some older applications that use VBA to write reports in Word; so I'm considering using WordML to write the reports.
Thanks.
Database Access
If you need a thin client, then it's probably better to stay away from directly accessing the database from within the client.
The main issue is that you will introduce a high dependency on a specific network architecture and both your ASP.Net application and the HTA will be highly dependent on the database.
Instead I would prefer to sever the dependency on direct line of sight to the DB and have the data to be handled by the server.
This has a few advantages:
for many small changes to the db, you're probably only going to have to update the ASP app.
if you ever need your client app to be functional over the internet (say because some users are going to an outside meeting, need to work from work or your company open a new branch) then you won't have to rewrite your thin client.
you keep better control over access to the resources: only let the ASP app talk to the database and filter what comes in/out of it.
This will saves you having to implement all security on the client: the ASP app becomes the guardian of the database. It's a much better way to secure information and it gives you a lot more control.
Reporting
For reporting I'd use the server again rather than implement complex reporting capabilities in the client itself.
The problem is that you'll always going to get limited on the client if you're using an HTA and don't want to start having to install dependencies on each user's machine.
You'll end-up building a thick client in no time...
If you're using ASP.Net there are plenty of really good reporting tools that will make your life much easier and allow your users to get nice reports in Excel, Word, PDF, etc without you having to code these features yourself.
Crystal Reports is ok, but there are better and simpler alternatives, for example the Developer Express Report engine is pretty easy to use.