The concept being conveyed is something which is definitely part of agile and relevant, the idea of pushing things off to the last responsible moment.
However the example taken actually relies on a completely false assumption to begin with:
that it is easier/less work to implement a flat-file database than use an RDBMS. -- Often completely false
Also are there any pros and cons of using any of them?
+ Relatively standard in the Windows environment.
+ Generally good support from installers, etc.
- Platform specific API, if you ever want to port your application.
- Not particularly human readable.
+ Simple format.
+ Human readable.
- May be difficult to store more ...
EntityFramework is a great tool, but like any great tool you would do yourself a great disservice to not understand the inner workings of how it translates a data model into a database schema, and also how it translates its own queries into SQL.
Everything works great until something goes wrong, then you are looking in log files trying to decipher the ...
Since you know you will be using a DB, there's not much point in writing code to handle flat files. You might get through a few iterations using some read-only CSVs but you'll quickly find yourself writing code that you know you will throw away.
One thing you can do to simplify the initial complexity by using something like SQLite (a library that gives you ...
I'd go with INI files, they are the more human friendly option:
width = 600
height = 350
position.x = 400
position.y = 200
path1 = "/some/random/path/"
path2 = "/some/other/random/path/"
name = "Yannis"
preference = "INI"
XML might be a good option, but it can't beat INIs' simplicity and elegance:
The EJB 3+ frameworks are actually pretty good as they came along with JPA as an answer for annotation configured Persistence frameworks, as well as CDI which allows for annotation configured dependency injection. You also add on top of that Weld. Spring on the other hand is just now catching up in the game with configuration through annotation.
With that ...
It's an example, used to demonstrate a concept, rather than a concept in and of itself.
The concept is that you don't make an architectural decision until the last responsible moment, but no later. But, in reality, you often do have a decision on the database you're going to use very early on. That might not be perfect, but it's a fact.
Once that decision ...
In "Effective Java" item 43 p. 201, Joshua Bloch says, "There is no reason ever to return null from an array- or collection-valued method." He recommends returning a zero-length array or an empty collection (Collections.emptyXxx) when there are legitimately no results. For one thing, it's a pain for the client to double-check everything:
if ( (retVal == ...
You've got value objects representing your business logic, containing business rules. Now you are adding a mechanism to persist them. Fair enough. How about you add a mechanism to read a database and construct them from it? Perhaps a static Load method taking IGetMyEntity instance as a parameter?
While you are at it, maybe it is the best to add a few more ...
You're doing it right. You're stamping data with its version, which means you have a definite interpretation of it. The only open question is how to handle "old" data. Your choices are essentially between upgrading data where it lives, having your code adapt the data in realtime, or having the code handle multiple data versions. From 30+ years experience,...
To expand Jeff D's suggestion of YAML, here's a brief intro.
YAML is similar to JSON (in fact, JSON is a subset of YAML since version 1.2 of the YAML standard, and can thus valid JSON can be parsed by YAML parsers). At first glance, the main difference being that YAML (by default) uses indentation rather than bracketing to show hierarchy. There is also a ...
My preference is XML files. They are hierarchical, you can bend them to your will in almost any way imaginable, they are well understood, platform independent, and there is a wide array of software available to read and write them.
Actually no. The basic database concepts will apply and you have to know some basic rules of what databases can do or else you'd face significant performance issues.
Entity Frameworks are useful to handle the conversion of mapping data from database records into objects. This allows developers to not have to deal with creating data access objects because ...
What are you persisting?
I am on an agile team and for one application, we persist almost everything to the database. Mind you, if we didn't then there wouldn't be much for this application to do - persisting things to a database is a large part of its raison d'être.
So: What are you persisting and what does your application do? If the application doesn't ...
There are many reasons why DTOs are used for persistence, but perhaps the nastiest one is database transactions. (i.e. where multiple steps are needed and you can't just perform a single neat UPDATE, INSERT, DELETE, etc.)
Some of the basic requirements for transactions are as follows:
Multiple steps can't easily be performed in a single neat SQL statement
Front end <--> API Service -> Service -> Repository -> DB
Right. This's the basic design by segregation of concerns proposed by Spring Framework. So you are in the "Spring's right way".
Despite Repositories are frequently used as DAOs, the truth is that Spring developers took the notion of Repository from Eric Evans' DDD. Repository interfaces will look ...
A lot of people misconstrue that aspect of agile as meaning they shouldn't plan ahead for future features. Nothing could be further from the truth. What you don't do is allow planning for future features to delay delivering value to your customers now.
How that applies to something like persistence depends very much on your application. One of my current ...
A search suggests that there will be multiple results which is an easy case - always return a collection. If there
are no results, then the collection will simply have no items.
If there can be 0 or 1 result, it depends on the semantics of the search. Can there only be a 1 result because
you are artificially limiting the search results to 1? I would go with ...
Your basic understanding is correct and the architecture you sketch out is good and works well.
Reading between the lines it seems like you are coming from a more database-centric active record style of programming? To get to a working implementation I would say you need to
1: Domain objects don't have to include the whole object graph. For example I could ...
Sounds like you want to use the JSON Merge Patch algorithm. From the abstract:
This specification defines the JSON merge patch format and processing
rules. The merge patch format is primarily intended for use with the
HTTP PATCH method as a means of describing a set of modifications to
a target resource's content.
EJB has a lot of baggage. Part of that baggage comes from the fact that it was targeted at the wrong audience. The other part was that the first two versions were utter crap.
If you look at the original EJB versions, the design was that an EJB developer could create a packaged solution that could be used within any EJB compliant container. For an in house ...
+1 to maple_shaft. I would add that even when you are using the (much balyhooed) EF Code First you are still modelling tables. It's been more than 20 years that people have used modelling and CASE tools that put an abstraction layer between themselves and the DDL script that builds their tables. That doesn't change the fact that they need to know how to ...
I believe you are correct in your assumptions A and B around persistence ignorance.
How you would best accomplish lazy loading of database objects is greatly dependent on your particular problem and implementation. However, I will attempt a generic answer to how to do lazy loading while still maintaining separation of concerns between persistence and ...
Your concerns are very much valid and they tell me your original easy caching solution is eventually becoming part of your architecture which naturally brings a new level of issues as you described yourself.
A good architectural solution to caching is to use annotations combined with IoC which solves several problems you described. For example:
Allow you ...
Databases are meant to store data that is rarely changed. That's the whole point.
Caches are meant to store data that is frequently used, to make access to it faster than the database would provide on its own.
Unless the data to be cached is very frequently used, or your company has a lot of money that it needs to waste, it makes little sense to cache it.
Yes, generally. You're then binding the type name to outside data, limiting your refactoring capabilities and making people change stuff in two places when they make a new class. Further, you're (or at least someone is...) going to be a world of hurt in ~10 years when C# becomes out of date. New implementations might not have the same classname, let alone ...
What I've done in the past is use PaperClip with Amazon S3 and CloudFront CDN for faster delivery. PaperClip supports S3 storage very nicely out of the box: see their documentation for S3 storage configuration options.
Set up a CloudFront distribution to forward image requests to your S3 bucket and other requests for static assets to your Ruby on Rails ...
I really don't think there is problem of VOs having an identity in database, as long as this identity remains hidden and transparent in domain layer itself. I would be data layer's responsibility to keep track of those identities so the domain doesn't have to care about it.
But VOs still give you ability to denormalize. Denormalization can have it's ...
How do I automate something (possibly a test) that tells me when I need to write a migration script and when I need to change the data's version number?
When your automated unit tests fail while importing old data into a newer model, that's one very clear indicator that you need to write a migration script/process.
Every time you make a code change that touches your serialization, you must add a new test case in your automated test suite that uses the new fields, or reads the old fields, etc. Over time you'll accumulate more and more coverage for your version transitions. As long as you run your test suite whenever you make changes you'll get notified when you stop ...