Hot answers tagged

111

Checking for uniqueness and then setting is an antipattern; it can always happen that the ID is inserted concurrently between checking time and writing time. Databases are equipped to deal with this problem through mechanisms like constraints and transactions; most programming languages aren't. Therefore, if you value data consistency, leave it to the expert ...


39

Consider what you're trying to achieve. Typically, the Command Query Response Segregation model works well for complex domains. The reason is that you're trying to do one of two things typically: Create/Update/Delete some complex domain entities Run analytic fetch queries (i.e. summation/aggregation queries) Hibernate works well for case 1 allowing you to ...


38

I think what you call “fail fast” and what I call it is not the same. Telling the database to make a change and handling the failure, that is fast. Your way is complicated, slow and not particularly reliable. That technique of yours is not fail fast, it is “preflighting”. There are sometimes good reasons, but not when you use a database.


32

Personally, I've tried making one huge schema for all my entities on a fairly complex but small project(~300 tables) . We had an extremely normalized database (5th form normalization (I say that loosely)) with many "many to many" relationships and extreme referential integrity enforcement. We also used a "single instance per request" strategy which I'm not ...


31

What you are describing as "Inline SQL" should really be called "string concatenation without parameterization," and you don't have to do that to use a Micro ORM safely. Consider this Dapper example: string sql = "SELECT * from user_profile WHERE FirstName LIKE @name;"; var result = connection.Query<Profile>(sql, new {name = "%"+name+"%"}); It's ...


22

To get this out of the way, I am a big proponent of Entity Framework, but it does come with some drawbacks that you need to be aware of. I also apologize for the long answer, but this is a very hot topic with many opinions and many required considerations. For small application, a lot of these considerations don't matter, but for enterprise-grade ...


20

This is actually a very difficult question to answer and I have found it to be a very controversial subject. As Yannis Rizos pointed out in his answer, having the constraint logic in both the database and the ORM layer would seem to violate DRY, which "can lead to maintenance nightmares, poor factoring, and logical contradictions". However, removing the ...


20

Android does not play as nicely with other frameworks as it could. Its recommended style of development assumes you build everything from its API, without other libraries. The UI layer is very tightly coupled to the model. This style is ideal for writing smaller, modular apps, not for complex applications. You need to give some thought as to whether you ...


20

MyBatis is SQL centric. It heps you calling SQL statements and mapping results (tables) to object trees. The main benefit is that it is not an ORM. It does not map tables to object so does not suffer the orm impedance mismatch. Fits well for complex or legacy databases or to use db features like stored procedures, views and so. It is quite simple and easy ...


16

Your application should still be modelled from domain driven design principles. Whether you use an ORM, straight JDBC, calling SPs (or whatever) should not matter. Hopefully a thin layer abstracting your model from the SPs should do the trick in this case. As another poster stated, you should view the SPs and their results as a service and map the results ...


16

ORMs(Object-relational mapping) are not mutually exclusive with Stored Procedures. Most ORMs can utilize stored procedures. Most ORMs generate Stored Procedures if you so choose. So it the issue is not either or. ORMs may generate unacceptable SQL (in terms of performance) and you may sometimes want to override that SQL with hand-crafted SQL. One of the ...


16

Your guiding principle should be Don’t Repeat Yourself: In software engineering, Don't Repeat Yourself (DRY) is a principle of software development aimed at reducing repetition of information of all kinds, especially useful in multi-tier architectures. The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative ...


15

This started as a comment but grew too large. No, as the other answers have stated, this pattern should not be used.* When dealing with systems that use asynchronous components, there will always be a race condition where the database (or file system, or other async system) may change between the check and the change. A check of this type is simply not a ...


13

ORMs often assume that the database exists to serve the ORM. But usually the database exists to serve the company, which might have hundreds and hundreds of apps written in multiple languages hitting it. But it's only a case of "ORM vs. Stored Procedures" if you're using an ORM that can't call a stored procedure. Otherwise, it's a case of deciding where to ...


13

There is definitely object-relational impedance. I had to deal with this for years on a product that kept its data on a database but was OO when it ran. As a vastly simplified example, consider three DB tables. Two are just lists, one containing people and one containing jobs. The third is a link between people and jobs, with a column for each. (And all ...


13

Let me start by simple clarification: I don't have experience with such large database so the rest of my answer is not based on the real world example. So you have a BIG database and you want to use it with ORM / EF. I would go with the second choice. Here is my simple explanation why: Mapping adds complexity. There is no need to add complexity with ...


12

Mark Seemann has an excellent blog post about this subject: IQueryable is Tight Coupling. He sums it up nicely in the final part (emphasis mine): You may think this is all a theoretical exercise, but it actually does matter. When writing Clean Code, it's important to design an API in such a way that it's clear what it does. An interface like this ...


12

The ORM provides an abstraction for your data layer to be independent of its RDBMS, but it may not be enough to "untie" your business layer from your data layer. Specifically, you should not let objects that map to RDBMS tables to "leak" directly into the business layer. At the very least, your business layer needs to program to interfaces that your ORM-...


12

That way lies madness. It is highly unlikely that you would ever need to change ORMs. And if you ever decide to change the ORM, the cost of rewriting the mappings will be a tiny fraction of the cost to develop and maintain your own meta-ORM. I would expect that you could write a few scripts to do 95% of the work needed to switch ORMs. In-house frameworks ...


12

Kinds of objects For purposes of our discussion, let's separate our objects into three different kinds: Business Domain logic These are the objects that get work done. They move money from one checking account to another, fulfill orders, and all of the other actions that we expect business software to take. Domain logic objects normally do not require ...


12

I think you are conflating repositories and generic repositories. A basic repository just interfaces your data store and provides methods to return the data IRepository { List<Data> GetDataById(string id); } It doesn't leak the data layer into your code via an IQueryable or other ways of passing in random queries and provides a well defined ...


11

The answer presented here is a quick answer and is not comprehensive, since the subject is rather big. Your question is about 3 things (at least): 1- Databases 2- SQL 3- ORM Concept A database is any repository of data. You can store your data wherever is appropriate for your application. SQL is a way to access this data when the data usually, SQL is ...


11

You have a couple of perfectly good scenarios already. There are lots of other reasons too. EF is really good at CRUD and at pretty straight forward reporting. Sometimes, though, EF is not the perfect tool. Some other reasons (scenarios) to consider using stored procedures in combination with Entity Framework would include: You have complex units of ...


10

I'm mostly with you; your colleague seems to be arguing either for the anemic domain model antipattern or for duplicating the model in a "persistence model" with no obvious benefit (I'm working on a Java project where this was done, and it's a massive maintainability headache, as it means three times the work whenever anything changes in the model). What ...


9

Author apparently refers to Dapper.Rainbow micro-ORM used in Stack Exchange Data Explorer. Project home page at NuGet Gallery - http://nuget.org/packages/Dapper.Rainbow Trivial micro-orm implemented on Dapper, provides with CRUD helpers. ... The implementation was extracted from http://data.stackexchange.com source at: http://code.google.com/p/stack-...


9

Unit testing the code relying on your DAL should be straight-forward: use the repository pattern to decouple your business layer from your ORM. Provide your POCOs by an abstract repository, then you can either provide a "real" repository in production (which uses your ORM), or a mock repository for testing purposes which delivers just test-data POCOs without ...


9

An ORM is not a requirement for any project of any scale. More often, small projects start with an ORM, then abandon it when scaling up. If database changes become too complex: Ask yourself why is the database changing too often. I had to work on projects where database was changed at least once per day, just because the project was badly thought, ...


9

At the end of the day an ORM is just an abstraction which generates sql for you and maps the data to your objects. Saving(tm) you some 'boiler plate' code. So there is nothing that ORMs as a whole necessarily are bad at by definition. The problem is that you don't use ORMs as a whole, you have to pick a specific one and use that! An individual ORM may ...


9

It would be wasteful to always fetch the entire objects. First I would question this. If your objects are well-designed and not too bloated, the performance and memory overhead of fetching them completely instead of getting them partially is often negligible for most real-world cases. The performance of SQL queries over a network are way more dependend on ...


8

For simplistic systems, with very basic data storage needs, I've often gone with a custom data layer which persisted to XML. However, to answer your question properly, we'll have to look at it from the perspective of most large companies. Why are we even keeping SQL and a SQL database as the back-end? One of the best answers that I can give you is that ...


Only top voted, non community-wiki answers of a minimum length are eligible