Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am considering NPoco for a large business application. I am a bit concerned that is it worth to develop a repository pattern?
I will need to handle complex SQL statements and extensive database operations on several entities in a same use case.
NPoco provides a variety of db operations functions, which I think will not be (directly) exposed to the consumer layer(s) by my repository layer.
Edit-1
Which approach is better to get most out of NPoco?
If you want to invest time in unit tests, then the Repository Pattern is worth it. However if most of your application logic is in stored procs and functions, then you will be limited with unit tests and just spend your time in integration testing.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I work on school enterprise project and I need create data layer with design patterns. Can you give me some hint where to start and how patters could I use ? Thanks
Edit:
I have not use frameworks for ORM.
You could try the repository pattern and unit of work pattern
One of the common pattern for the data layer is the Data Access Objects. Anyway you can also use ready-to-use libraries such as the Microsoft Solution Entity Framework or NHibernate.
Also you can read this link with a lot of suggestions
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am supposed to develop an enterprise-class ASP.NET Web Application that supports multiple companies.
What are the pros and cons to create separate databases for each company? Won’t it very resource consuming for a server to support connections to multiple databases or it’s better to have only one database? Let’s say I have 2000 companies and each of them has 100 employees.
What is the best approach to design the system in this case?
You might be interested in the below links:
Multi-Tenant Data Architecture
Stack Exchange
SO
Pros: Much faster querying; better overall performance, security and scale-ability; easier fine tuning of each individual database, easier deployment and troubleshooting.
Cons: maintaining 2000 backup jobs
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
The project I work on has multiple layers and each layer's object is being used in the subsequent layer. But some of the classes do not have any interfaces and have non virtual methods. So basically I will not be able to use a mock framework to stud those classes from other layers. When I asked the developer to create an interface for the same class, so that I can mock it, he asked me why should I create an interface if I am not going to reuse it.
Is it a good practice to write interface just to improve the testability of the code?
Your code should be loosely coupled and has good dependency management to allow you write unit-tests easily. If you can't write unit-tests easily, it's the first sign that your code is not well-architectured enough, and you need to refactor it. So, your motivation to change production code(in your case to add Interface) should be to make your code better, not just to aid testing. If you could do the first - you would get the second for free.
Btw, one of the main benefits of following the TDD practice is that the good architecture is enforced from the beginning: it's difficult to write untestable code, because you write tests before you write code.
So, the answer is YES, it's OK to add Interface, but it should be done for the sake of good architecture, not just to help you write tests for bad architecture.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I build a framework that is for high traffic site, the site only for other application site log records.
I used redis or file in the middle layer to cache log
In a certain period of time, the program will take cache into the database.
Because there is a large amount of data, I need a ORM what is lightweight and agile .
I use Mysql5.x, because the SQL server of the relatively high price.
I am more familiar with ibatis (for Java),but ibatis.net was not update for two years, so, ibatis.net whether can meet the requirements?
if ibatis can do it,I can reduce a lot of learning time.
Or are you any better suggestions?
c#'s new technology, I am not very familiar with, please pointing
For anything high performance, I use Dapper. It's a micro-ORM with very high performance developed and used by the very website your are seeing! (stackoverflow.com).
It has a NuGet package too, which you can install by Install-Package Dapper command in package manager console.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
In theory, it is difficult to perform tests on functional code bases that need interactions with database, but I think we can use mocks. In real life applications, do you have failed cases when applying mocks to perform TDD tests with databases ? Could you shared some thoughts to explain this to me?
In tdd i use mocks to replace the physical database access with a fake (mock).
For databaseaccess i am always using a The Repository Pattern as api which can be easily mocked.
To Answer your question:
> do you have failed cases when applying mocks
> to perform TDD tests with databases ?
No as long all database-operations are encapsulated in the repository.