Ricardo Cavalcanti has raised question on fluent passing of parameters into the queries encapsulated by the QueryFor (specification) pattern.
Let’s talk about the easiest option of passing parameters, first. It requires no new code at all and is just about chaining queries:
var list = customers
.Find<ImportantCustomers>()
.Where(c => c.City == "Ufa");
Where comes from the in line extension method provided by Linq.
However, in certain situations Linq might be not enough. This involves queries that encapsulate come complex business logic or require parameter pre-processing, that you want to hide away.
Continue reading ‘Linq queries with parameters for your ORM IRepository’
Let’s get back to the discussion from XPO+ORM+IOC series on Implementing ORM-independent Linq queries.
As you can see from the previous post, there are 3 options to abstract away queries in a testable manner (and we will add one theoretical one for the Boo):
1. Put queries right into some domain-specific repository implementation (i.e.: CustomerRepository.FindImportantCustomers) and ask the container about it.
- Pro: Simple and looks as if there is no logical separation between the repository and queries
- Con: Low scalability
- Con: Coupled code that would take some effort to test
2. Put queries into the extensions that use Repository[T].Find method.
- Pro: A bit more abstraction and testability, than in the previous option
- Con: Does not make a lot of sense
Continue reading ‘Options of separating queries from the ORM Repository’
Company buys some business framework that seems to match their needs in the short-term perspective. It is easy and fun to use it initially - you just need to work with some big building blocks and the framework will do the rest for you.
As the time goes, company gets to met new requirements that steer to them from the probable future that they’ve never considered (this always happens). Every encounter will be like a gamble. You’ve got 80% that you can deliver solution that meets this requirement using just the provided building blocks.
And there is 20% chance that you will just will not have LEGOs for a trivial task of simply adding a nice porch to the house (and if you keep on gambling, you will always lose, unless you control the game).
Continue reading ‘You can build a house with big LEGO blocks. Can you add a nice porch?’
Empirical observation from the Project Management field of knowledge tells us that planning ahead of time saves a lot of resources down the road (entire PMBoK thing is basically just about this and the common dictionary thing).
As the level of complexity increases, projects require more planning in order to be efficient and succeed. Large-scale construction projects is one of the most vivid examples of that.
So, why do not people use similar principles in the development widely? Then, we could improve our success rate and save the resources by implementing certain functionality just with the component interactions (vertical solution architecture) instead of hard coding it. And I’m not even talking about constant quality, efficiency and risk management.
Reasons like “you just do not have the crystal ball to know about all the requirements” or “development is an art, and you can neither plan or control this” just do not seem to be valid.
- A. You can know about all the requirements that matter or that could matter (you just need to concentrate on these). All the information is available. You just have to work hard with it.
- B. Development is purely about logics (although efficient logical compositions are beautiful, just like it is with the math equations). If the same unit-test being run three times could fail once due to some unpredictable magic, then this would be art to develop something stable in such environment.
PS: the answer to the “Why” question is simple - the development looks too easy to start these days, while planning requires some effort. However, as the project goes - they swap places.
PPS: There actually are development situations where non-deterministic test results are possible (i.e.: sampling performance of neural network “learning” speed or the capability of evolution algorithms to avoid local extrema). Dealing with these could be considered an art. Fortunately, every-day development projects rarely have to deal with these.
Latest Comments