Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Can someone please explain to me the Repository Pattern in .NET, step by step giving a very simple example or demo.
I know this is a very common question but so far I haven't found a satisfactory answer.
As a summary, I would describe the wider impact of the repository pattern. It allows all of your code to use objects without having to know how the objects are persisted. All of the knowledge of persistence, including mapping from tables to objects, is safely contained in the repository.
Very often, you will find SQL queries scattered in the codebase and when you come to add a column to a table you have to search code files to try and find usages of a table. The impact of the change is far-reaching.
With the repository pattern, you would only need to change one object and one repository. The impact is very small.
Perhaps it would help to think about why you would use the repository pattern. Here are some reasons:
You have a single place to make changes to your data access
You have a single place responsible for a set of tables (usually)
It is easy to replace a repository with a fake implementation for testing - so you don't need to have a database available to your unit tests
There are other benefits too, for example, if you were using MySQL and wanted to switch to SQL Server - but I have never actually seen this in practice!
This is a nice example: The Repository Pattern Example in C#
Basically, repository hides the details of how exactly the data is being fetched/persisted from/to the database. Under the covers:
for reading, it creates the query satisfying the supplied criteria and returns the result set
for writing, it issues the commands necessary to make the underlying persistence engine (e.g. an SQL database) save the data
Related
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 2 years ago.
Improve this question
let's say you have 5 concrete classes implementing the interface IResult. And you want to work with many diffrent concrete objects that are stored in a database.
I am working with C# and a SQL database.
I have 2 diffrent ways in Mind:
Approach1:
You perform one large database request where you get data in their concrete form that you can put in a List because saving it in 5 diffrent lists is not great in case you want to add mor concrete classes. At least in my opinion. If you now need a concrete Object you have to use one cast when ever you need the concrete instance wich results in many many casts at the end.
Approach2:
You perform a database request everytime you need one concrete object and after doing something with it you throw it away. This way you dont need to cast when ever you need a concrete instance but you have to perform many many database requests.
can anyone please tell me wich way is faster performance wise?
Thank you
Always, without exception, one large properly built query. Every time you hit the DB server you introduce your network latency twice in your operations (plus the query time itself), which adds up to ridiculous amounts of wait time.
I see the close votes and that guy commenting with the witty "did you profile it?", but you can safely ignore them, the answer is absolutely clear cut: one query.
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 8 years ago.
Improve this question
I am currently exploring of using Entity framework for the windows based (forms) application I'm developing that does data mining for a dataset of more than 1 million rows (my datasources are from oracle, sql server, sqlite). What the application will do is I parse these information to the users local client, and I utilize linq to objects in mining useful information. The said application shall only read information to the source database as its output is written in an excel file.
Given the significant ease of using the Entity Framework in terms of reducing the development time (this is the first time I will be using an ORM, and coding the necessary dataaccess objects takes about 80% of my time based on the previous projects I've done before), I would like to ask if it's worth it to use EntityFramework to the application I'm working in? How much would be the performance drop (as compared to using DataReaders) when reading tables for over 1 Million rows?
Also, given that I'm new to this technology, I would much appreciate it if you could refer me to useful tutorials and best practices.
Using pure ADO.NET will give you practically best performance you could get. But bear in mind that after you fetch data from data source, you would still need to map results to your object model (something that is done by EF automatically) so that you can perform actual data mining.
Mapping could be tough or easy process to do depending on how complex your data model is. For example, Entity Framework is good at mapping hierarchical data structures, which is useful when fetching related entities (or even their related entities) along with the actual entity.
You should also consider how often does your data model changes (and how big those changes are), so you calculate maintainability cost too. Having tons of SQL that you have to change every time you add new column is another point of getting problems. In this case, maintaining EF model with POCO's would be easier and more convenient.
Note that there are other O/RMs that can give you kind of best of two worlds (performance of DataReader and easy mapping to POCOs of Entity Framework). Among these are: NPoco (former PetaPoco), Dapper (the one used at StackOverflow), NHibernate (using HQL can be quite fast), OrmLite (has basic LINQ-like queries support) and many others.
Take a look at Dapper's performance benchmarks results that might give you some picture of what performance can be achieved with popular O/RMs.
Performance of either technology of fetching data is really dependent on what data model you have in the database.
That's why it's important not only to analyze existing benchmarks, but also perform your own based on your particular use cases on your data model. As a starting point, you can grab Dapper's performance tests code and tweak it according to your needs (data model, typical queries, etc), so that you get more comprehensive and realistic performance results using different frameworks.
EF is never as fast as using raw ADO.NET with an OracleCommand. After all, EF is another layer on top of ADO.NET; it's main goal is to provide programmers with convenience features of mapping raw columns into fields and rows into objects.
If you need the absolute top-notch performance, then you need to use raw ADO.NET. The downside of this is the fact that you need to start fiddling around with untyped rows and columns.
There ain't no free lunch - either you have top performance but an unpleasant programming API, or you get convenience and productivity - at a performance price.
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
I'm currently learning LINQ especially SQL requests with the entity framework.
I used to write native SQL-queries before, and I've implemented it with one class in my projects called "SQL_Connection" or something.
So I had all my SQL-procedures stored in one class.
Now as I'm willed to learn the entity framework the right and cleanest way from beginning, I'm asking myself where do I put all those linq-procedures I create during a project.
Do expierienced people put them in the class-file of the related class, or are they using a big sql-class where all those procedures are stored in?
I'm asking myself where do I put all those linq-procedures I create during a project.
Where you create them.
If you are not totally ignorant on .NET you will have a TON of LINQ queries and only SOME will be EF related - the syntax is the same. You will use LINQ in your code to sum and aggregate in memory arrays, and do a lot of things.
The beauty of LINQ is that all changes to the underlying provider are isolated and / or checked by the compiler, so there is no need to have all in one place "in case I rename a table".
I keep the LINQ where I need it. This allows me to isolate layers without having a mother of all queries class. Especiall as some of the LINQ queries are multi step queries involving one or more data access then grouping and correlating in memory.
Seriously, the "one class to rule them all" (sql) is an artefact of the fact that SQL is a string, so in case of a database change you need to find all SQL that touches that changed element and that please without going through tons of code. This is absolutely not needed with LINQ.
That's up to your pleasure. Answering the question: do create BLL classes for your related set of objects. By this, a minor change won't make you itchy. Assume you added a new column to a table, having that table's (and other related ones') operations located easily is good, right? Avoid too big files. Try to stay modular and etc.
If you need a reading, check out this Wiki link about MVC 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 8 years ago.
Improve this question
I'm running an email marketing program that runs and schedules campaigns. So I have two types of campaigns in it:
Ad hoc
Scheduled
And since I want my program to create one campaign at a time. I think I'm going to need Singleton pattern.
Each campaign has attributes that are common and attributes that are specific. E.g. Adhoc campaign does not need a time schedule. Also a scheduled campaign reads from a pre-written SQL file while ad hoc campaigns are run instantly.
I would like to have a well-structured design to support these. Is a combination of Factory and Singleton the answer?
If so, can I have a simplified example?
If not, what do you recommend?
Patterns are nice, but a pattern is a solution to a specific problem. You don't seem to have any of those specific problems.
From your requirements, you need a single variable of a base-type and an if-statement to put either one or another derived class into it.
If you want noodles, you have to decide if it should be spaghetti or tortellini. Pick one, heat, eat. Please don't build a NoodleHeatingAbstractFactory that only allows heating of a single, well guarded noodle dish. Keep it simple.
You typical use singletons when you want a global shared resource. To have one instance of something you don't necessarily need a singleton unless it is created from multiple locations, if not you can just create one instance and pass it around. I think AbstractFactory fits well here, but not sure about Singleton.
Update
If the user chooses which campaign to create I don't think you need a factory. Just create the appropriate campaign and you can store it in a ServiceLocator which is usually a Singleton or alternatively inject it into each Form/Window that you create.
The dependency injection Tends to be a it easier to unit test as you can mock the campaign
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 9 years ago.
Improve this question
I am learning C# and I want to access a database. I have been searching pages on .net database connectivity for the last two - three days. I also came to know that it has several ways for the connectivity and this is exactly where my mind started to ask a number of questions. Please tell me if I am wrong in my understanding.
Check out this Diagram 1.
Now what I am getting here are five ways of connectivity:
Linq to Objects
Linq to Datasets
Linq to SQL
Linq to Entities
Linq to XML
Here is another Diagram 2 of ADO.net Architecture -
I have read the definitions, but am not able to differentiate the functionality and purposes. Can anyone give me a short explanation of both diagrams for my understanding?
Suppose I am a programmer who write code in C#; which way should I
prefer to write desktop based has database connectivity that
has future?
To Software Developer is it needed to go through all the
preceding ways of data access from database?
For the answer to number 1, use Entity Framework and a database. The database could be relational (like SQL Server), or document-based (like MongoDb). If you just grab the free Visual Studio 2013 express and start by creating a new project from a template, you'll probably end up with some version of SQL Server to start out with.
You have a lot of options for Linq to Whatever because sometimes you just have to get data out of repository and if you can use Linq as a facade to it, then getting your data out is that much easier because it feels a lot like getting data out of a database. There's even Linq to Twitter. For a brand new project though, you'll most likely use a database.
For the answer to number 2, you would only do that on an existing application that you are maintaining. It is fine technology, but if you're creating a new project, use Entity Framework.
Under the covers of all the data libraries, every time you access the database three things happen:
- a connection is made to the database
- a command is created (to select, update, insert or delete data)
- the command is executed in the database
In the case of LINQ or EF, the SQL for the command is generated automatically from your objects, but ultimately, the same three actions happen.
If you want to understand the basics, start with the ADO.NET objects. If you want to get something running more quickly take a look at EF, or nHibernate.