You know WPF, but do you know .Net Core?

MrL

@Zenith said in You know WPF, but do you know .Net Core?:

@MrL said in You know WPF, but do you know .Net Core?:

Well, that's horrible, what can I say.

It's also easier to debug, easier to test, easier to maintain, and faster to execute. So take your metric ton of dependency injection framework boilerplate spaghetti and bring somebody else's server farm to its knees.

Your projects are either simple enough that it makes sense, or horrible to work in.

If I had to deal with instantiation of dependencies and their lifecycle in my projects, I would cut myself. Every day probably.

@Zenith said in You know WPF, but do you know .Net Core?:

@MrL said in You know WPF, but do you know .Net Core?:

That's a good thing.

Not when it's replaced by dumb web service APIs that transmit an entire recordset just to get the length written by developers that don't understand computing concepts because it's all hidden under a game of buzzword bingo. And I'm posting this separately because the magic JavaScript dependency injection framework powering this site can't scroll a fucking textbox.

Competent developers are hard to come by and most people are idiots. It's always been like this, always will be. Nothing to do with wonders of pointer arithmetic.

topspin

@Kamil-Podlesak said in You know WPF, but do you know .Net Core?:

@topspin said in You know WPF, but do you know .Net Core?:

@PotatoEngineer said in You know WPF, but do you know .Net Core?:

Sooner or later, I'd end up sticking these things into globals, and later, creating a global store of these dependencies to make it easier to get at them from awkward parts of code, and then... I've just reimplemented IoC, badly.

So basically the IoC implementation is just a container of global variables?

The bad one, yes.

What is the good one then?
Note that I was speaking of what it is effectively, not how it's done under the hood. Is sounds like you just say "here's a global variable with a name" on one side and "give me the global variable with a name" on the other side, so that you don't have to pass the variables down the dependency tree. Which is just another way to do global variables.

You can have several different set of globals at once.

How does it know which one to pick?

dkf

@Zenith said in You know WPF, but do you know .Net Core?:

I really don't get the point of dependency injection, though the disadvantages are awfully familiar.

Somebody said in A quick intro to Dependency Injection: what it is, and when to use it

Disadvantages of DI

It’s a bit complex to learn, and if overused can lead to management issues and other problems.

Many compile time errors are pushed to run-time.

Dependency injection frameworks are implemented with reflection or dynamic programming. This can hinder use of IDE automation, such as “find references”, “show call hierarchy” and safe refactoring.

Couldn't you achieve exactly the same "replace objects" functionality if your code said
function BlahBlah ()
{
  IObject something = Zenith.Factory.GetIObject();
  IObject somethingElse = Zenith.Factory.GetIObject(Reflection.GetCaller());
}
instead of
function BlahBlah ()
{
  ObjectA something = new ObjectA();
}
?

Edit: I also don't see any proof of "less boilerplate" that listed as an advantage. My experience with modern fads like DI/IoC has been orders of magnitude more boilerplate.

DI/IoC isn't necessary with a simple application, but as applications get more complex then it becomes nice to move much of the startup and shutdown boilerplate into a framework. That's what the DI/IoC container is: it works out what order to make objects, how to wire them together, how to configure them, when to call appropriate shutdown methods, all that jazz. Could I do it by hand? Sure! But it's a lot of complexity that isn't the stuff that my application really cares about (the business logic itself is quite complicated enough!) and when there's a non-trivial mix of object lifetimes and scopes about, it's nice to farm out that mess.

I note that this matter seems to be much more of a debate in C#-land than when working in Java. I guess it's because Java's got a very good DI/IoC container framework and everyone just uses that rather than spending effort on debating the bleeding obvious. Yes, people make fun of Spring's internal naming conventions, but as a user of it, you hardly ever need to look into the cesspit (and convention is that you shouldn't!)

Kamil Podlesak

@topspin said in You know WPF, but do you know .Net Core?:

@Kamil-Podlesak said in You know WPF, but do you know .Net Core?:

@topspin said in You know WPF, but do you know .Net Core?:

@PotatoEngineer said in You know WPF, but do you know .Net Core?:

Sooner or later, I'd end up sticking these things into globals, and later, creating a global store of these dependencies to make it easier to get at them from awkward parts of code, and then... I've just reimplemented IoC, badly.

So basically the IoC implementation is just a container of global variables?

The bad one, yes.

What is the good one then?

The one that is not created by accident?

Note that I was speaking of what it is effectively, not how it's done under the hood. Is sounds like you just say "here's a global variable with a name" on one side and "give me the global variable with a name" on the other side, so that you don't have to pass the variables down the dependency tree. Which is just another way to do global variables.

Well, yes, that is definitely a one way to look at it. It's also how the non-IoC DI usually work (sometimes with some thread-local magic to work around the limit of single global context).

You can have several different set of globals at once.

How does it know which one to pick?

I cannot answer this, the question does not make sense to me.

Kamil Podlesak

@dkf said in You know WPF, but do you know .Net Core?:

I note that this matter seems to be much more of a debate in C#-land than when working in Java. I guess it's because Java's got a very good DI/IoC container framework and everyone just uses that rather than spending effort on debating the bleeding obvious.

I think it's just a product of different culture. J2EE server were always insane overcomplicated and overpriced mess (I believe I have already mentioned IBM today, have I?), which created strong incentive for alternative solutions; this is combined with Java being completely free, which created strong culture of FREE alternative solutions. Microsoft's offer was better and less convoluted, plus the whole developer culture was completely closed. I distinctly remember the first time I have worked with C# developers; they genuinely refused to use anything that was available in Windows Update

IMHO it's just a coincidence that the IoC idea came about the same time and Spring jumped on it. But there are other (and arguably better) IoC containers; Spring just comes with "batteries included". So, basically, it's popularity is similar to popularity of python in some areas.

Yes, people make fun of Spring's internal naming conventions, but as a user of it, you hardly ever need to look into the cesspit (and convention is that you shouldn't!)

This is actually very interesting; the whole AbstractSingletonProxyFactoryBean meme is usually used to mock Design Pattern or even OOP in general. But it does not have anything to do with that, except some naming convention maybe taken from GOF book. In reality, it's and internal class and part of very convoluted magic used to circumvent the lack of metaprogramming in Java. Yes, the very need mucking around with reflection is a , but it's completely different .

is that the mainstream languages still use design from 1980s.

izzion

@topspin said in You know WPF, but do you know .Net Core?:

You can have several different set of globals at once.

How does it know which one to pick?

When you register things with the container, you can specify the scope (per request, per lifetime, etc). So if you're running a web API and you register your DBContext and your controllers and the logic dependencies of those per request, the IoC container will create a new copy of each one for every request, and keep them separate from the copies for other requests. But your configuration values (which are probably constant anyway) could be registered per lifetime and every request could share the same one for memory / performance / caching sake.

Kamil Podlesak

@izzion said in You know WPF, but do you know .Net Core?:

@topspin said in You know WPF, but do you know .Net Core?:

You can have several different set of globals at once.

How does it know which one to pick?

When you register things with the container, you can specify the scope (per request, per lifetime, etc). So if you're running a web API and you register your DBContext and your controllers and the logic dependencies of those per request, the IoC container will create a new copy of each one for every request, and keep them separate from the copies for other requests. But your configuration values (which are probably constant anyway) could be registered per lifetime and every request could share the same one for memory / performance / caching sake.

That is definitely a feature of some IoC containers (but not all of them). In any case, however, the value is taken from the same container that the object is created in (usually, created by).

dkf

@Kamil-Podlesak said in You know WPF, but do you know .Net Core?:

That is definitely a feature of some IoC containers (but not all of them).

It's a useful feature; you describe what the natural lifetime of objects of a class is (usually pretty easy from the perspective of the class developer) and then all the clients of the class's objects don't have to care very much about the rest of the details. Having the container manage the object lifetimes (where they're not just immediate things that will be disposed of in microseconds) reduces the complexity of understanding. And the models of that sort of thing used by frameworks are generally at least as good as anything you'd bother to cook up yourself.

Groaner

@xaade said in You know WPF, but do you know .Net Core?:

I never understood why the actual technical stack is so important when the differences are very minor.

I mean, just how many years of experience you want in .Net Framework AND .Net Core?

.Net Core just came out recently, so that means any candidates who do not already have 15 years of experience in it can be summarily rejected. Next question, please.

Would you mind telling me how they're using Core, that's so much more important to whether I have the experience.

Thanks.

Can't do that. Our client is working on a highly secret proprietary system and details are on a need-to-know basis.

Groaner

@izzion said in You know WPF, but do you know .Net Core?:

@xaade said in You know WPF, but do you know .Net Core?:

I never understood why the actual technical stack is so important when the differences are very minor.

I mean, just how many years of experience you want in .Net Framework AND .Net Core?

Would you mind telling me how they're using Core, that's so much more important to whether I have the experience.

Thanks.

I could see some concern if a developer was exclusively .NET Framework (which didn't have Dependency Injection as a built-in feature and is much more likely to have old legacy apps that didn't really do much unit testing / TDD patterns), but you were hiring for a code base that was .NET Core and leveraging the improved handling for DI/IoC and such that is built in now.

As a developer who came from exclusively .NET framework without dependency injection, I can attest that there isn't much ground that needs to be covered. All that developer needs to know is that s/he now has to update twice as many files any time a change needs to be made to anything, to satisfy unit tests that may or may not ever be exercised, and that the maintenance effort for even the smallest of changes may be tedious enough to drive the developer to seek comfort using more literal forms of "dependency injection," if you catch my drift.

Meanwhile, that legacy stored-procedures-and-aspx webapp requires only changing a stored procedure and the .aspx page to achieve the same ends.

Likewise, if they're using EF Core, the behavior is somewhat different than EF Framework, and less forgiving of some of the lazy LINQ that EF Framework let you get away with (and just switched into "performance suck" mode automatically).

Why would you have developers writing queries? I thought only DBAs were allowed to touch the database.

Groaner

@error said in You know WPF, but do you know .Net Core?:

I thought DI was more of a design antipattern.

FTFY

Groaner

@Zenith said in You know WPF, but do you know .Net Core?:

I really don't get the point of dependency injection, though the disadvantages are awfully familiar.

Somebody said in A quick intro to Dependency Injection: what it is, and when to use it

Disadvantages of DI

It’s a bit complex to learn, and if overused can lead to management issues and other problems.

Many compile time errors are pushed to run-time.

Dependency injection frameworks are implemented with reflection or dynamic programming. This can hinder use of IDE automation, such as “find references”, “show call hierarchy” and safe refactoring.

You mean you don't like getting a random exception that's difficult to track down because you forgot to add a binding between IControllerRepositoryFactoryRegistry and ControllerRepositoryFactoryRegistry in your IoC configuration, even though ControllerRepositoryFactoryRegistry is the only class that implements IControllerRepositoryFactoryRegistry?

Groaner

@loopback0 said in You know WPF, but do you know .Net Core?:

@Rhywden said in You know WPF, but do you know .Net Core?:

Quick question. How would you support different databases? I.e. your application only needs one actual DB in production but it could be either MongoDB, PostgreSQL, SQLite or ... Oracle

You wouldn't unless you enjoy punishing yourself

One shop I was at forbade the use of bit columns because someday the application might need to be ported to Oracle. An application, mind you, that already had many SELECTs without a FROM DUAL, and dealt with tables that might at worst have no more than 100k rows.

Groaner

@PotatoEngineer said in You know WPF, but do you know .Net Core?:

if the controller was a giant pile of stubs that passed all of their logic to ServiceNamedAfterTheController

... which in turn calls RepositoryNamedAfterTheController? How did you guess?

Zenith

@Groaner said in You know WPF, but do you know .Net Core?:

@Zenith said in You know WPF, but do you know .Net Core?:

I really don't get the point of dependency injection, though the disadvantages are awfully familiar.

Somebody said in A quick intro to Dependency Injection: what it is, and when to use it

Disadvantages of DI

It’s a bit complex to learn, and if overused can lead to management issues and other problems.

Many compile time errors are pushed to run-time.

Dependency injection frameworks are implemented with reflection or dynamic programming. This can hinder use of IDE automation, such as “find references”, “show call hierarchy” and safe refactoring.

You mean you don't like getting a random exception that's difficult to track down because you forgot to add a binding between IControllerRepositoryFactoryRegistry and ControllerRepositoryFactoryRegistry in your IoC configuration, even though ControllerRepositoryFactoryRegistry is the only class that implements IControllerRepositoryFactoryRegistry?

Oh, you mean like those awesome "exception thrown by target of invocation" exceptions that always crop up when reflection shits the bed?

Gąska

@Groaner said in You know WPF, but do you know .Net Core?:

@Zenith said in You know WPF, but do you know .Net Core?:

I really don't get the point of dependency injection, though the disadvantages are awfully familiar.

Somebody said in A quick intro to Dependency Injection: what it is, and when to use it

Disadvantages of DI

It’s a bit complex to learn, and if overused can lead to management issues and other problems.

Many compile time errors are pushed to run-time.

Dependency injection frameworks are implemented with reflection or dynamic programming. This can hinder use of IDE automation, such as “find references”, “show call hierarchy” and safe refactoring.

You mean you don't like getting a random exception that's difficult to track down because you forgot to add a binding between IControllerRepositoryFactoryRegistry and ControllerRepositoryFactoryRegistry in your IoC configuration, even though ControllerRepositoryFactoryRegistry is the only class that implements IControllerRepositoryFactoryRegistry?

I don't. That's why I have system tests and CI.

Groaner

@topspin said in You know WPF, but do you know .Net Core?:

@Gąska said in You know WPF, but do you know .Net Core?:

@topspin said in You know WPF, but do you know .Net Core?:

@PotatoEngineer so what’s the advantage over globals if it’s just pretend-not-to-be-globals?

You know where they are. And that's about it.

That’s a good point actually, but I don’t need a framework for that.

That sounds like one of those problems that was forever solved by Intellisense such that all the ugly half-measure solutions could go away forever. Other such half-measure solutions might include:

Prefixing all member variables with m to make clear that they're members (e.g. mName, mBeginDate)
Spolsky's Systems Hungarian where cpWidth meant "width in count of pixels" instead of creating a class called PixelWidth which could not directly be assigned to an integer or vice-versa without explicit conversion

Groaner

@Zenith said in You know WPF, but do you know .Net Core?:

@Groaner said in You know WPF, but do you know .Net Core?:

@Zenith said in You know WPF, but do you know .Net Core?:

I really don't get the point of dependency injection, though the disadvantages are awfully familiar.

Somebody said in A quick intro to Dependency Injection: what it is, and when to use it

Disadvantages of DI

It’s a bit complex to learn, and if overused can lead to management issues and other problems.

Many compile time errors are pushed to run-time.

Dependency injection frameworks are implemented with reflection or dynamic programming. This can hinder use of IDE automation, such as “find references”, “show call hierarchy” and safe refactoring.

You mean you don't like getting a random exception that's difficult to track down because you forgot to add a binding between IControllerRepositoryFactoryRegistry and ControllerRepositoryFactoryRegistry in your IoC configuration, even though ControllerRepositoryFactoryRegistry is the only class that implements IControllerRepositoryFactoryRegistry?

Oh, you mean like those awesome "exception thrown by target of invocation" exceptions that always crop up when reflection shits the bed?

Yes, those. Instead of exceptions in your code where you can inspect variables and get insights into what led to the exception in the first place.

Gąska

@Groaner said in You know WPF, but do you know .Net Core?:

@topspin said in You know WPF, but do you know .Net Core?:

@Gąska said in You know WPF, but do you know .Net Core?:

@topspin said in You know WPF, but do you know .Net Core?:

@PotatoEngineer so what’s the advantage over globals if it’s just pretend-not-to-be-globals?

You know where they are. And that's about it.

That’s a good point actually, but I don’t need a framework for that.

That sounds like one of those problems that was forever solved by Intellisense such that all the ugly half-measure solutions could go away forever.

Go make your Intellisense list each and every static member in your entire codebase that's ever modified by anything, but only those that are modified. I'll wait.

Gribnit

@Zenith said in You know WPF, but do you know .Net Core?:

@MrL said in You know WPF, but do you know .Net Core?:

That's Factory - you need to write instantiation code and worry about instances' lifecycle/state yourself.
namespace Zenith
{
  static class Factory
  {
    IObject GetIObject()
    {
      return new SomethingThatImplmentsIObject();
    }
  }
)
Oh no, I have to call a constructor.

I started with C++ and call Win32 in my C#, so I know all about pointers and references and marshaling and so on, and I never see any of that in modern development. Even the using keyword throws the "developers" on these jobs for a loop. My own patterns lean heavily towards static functions where by design I don't throw many objects with lifecycles around at all.

"Many" as in
You created dependency tree that is impossible to construct.
or
You forgot to register something in the container.

Another way of reading that is that you have the same two errors, and side effects of them, repeatedly. You know, like when JavaScript just stops executing because it has typos because it never ran through a compiler before deployment.

Ah, well, it's good that you now treasure your irrelevance.

Gribnit

@MrL said in You know WPF, but do you know .Net Core?:

@Zenith said in You know WPF, but do you know .Net Core?:

@MrL said in You know WPF, but do you know .Net Core?:

Well, that's horrible, what can I say.

It's also easier to debug, easier to test, easier to maintain, and faster to execute. So take your metric ton of dependency injection framework boilerplate spaghetti and bring somebody else's server farm to its knees.

Your projects are either simple enough that it makes sense, or horrible to work in.

If I had to deal with instantiation of dependencies and their lifecycle in my projects, I would cut myself. Every day probably.

@Zenith said in You know WPF, but do you know .Net Core?:

@MrL said in You know WPF, but do you know .Net Core?:

That's a good thing.

Not when it's replaced by dumb web service APIs that transmit an entire recordset just to get the length written by developers that don't understand computing concepts because it's all hidden under a game of buzzword bingo. And I'm posting this separately because the magic JavaScript dependency injection framework powering this site can't scroll a fucking textbox.

Competent developers are hard to come by and most people are idiots. It's always been like this, always will be. Nothing to do with wonders of pointer arithmetic.

And then there's those that have finished learning.

Groaner

@Gribnit said in You know WPF, but do you know .Net Core?:

@Zenith said in You know WPF, but do you know .Net Core?:
@MrL said in You know WPF, but do you know .Net Core?:

That's Factory - you need to write instantiation code and worry about instances' lifecycle/state yourself.
namespace Zenith
{
  static class Factory
  {
    IObject GetIObject()
    {
      return new SomethingThatImplmentsIObject();
    }
  }
)
Oh no, I have to call a constructor.

I started with C++ and call Win32 in my C#, so I know all about pointers and references and marshaling and so on, and I never see any of that in modern development. Even the using keyword throws the "developers" on these jobs for a loop. My own patterns lean heavily towards static functions where by design I don't throw many objects with lifecycles around at all.

"Many" as in
You created dependency tree that is impossible to construct.
or
You forgot to register something in the container.

Another way of reading that is that you have the same two errors, and side effects of them, repeatedly. You know, like when JavaScript just stops executing because it has typos because it never ran through a compiler before deployment.
Ah, well, it's good that you now treasure your irrelevance.

In about a billion years, the sun will have gotten so hot that life on Earth as we know it will no longer be a thing, and given the intransigence of the "we shouldn't go to space until we've solved all our problems down here" crowd, along with their natural allies, the flat-earthers who contend that the Earth cannot be round because they cannot conceive of a round planet unless it's the size of Asteroid B612, the outlook does not look good for our species.

And in the much nearer term, can you find someone under 30 who isn't a film buff and knows who Clark Gable was? Irrelevance is fate.

topspin

@Groaner said in You know WPF, but do you know .Net Core?:

can you find someone under 30

No.

Gribnit

@Groaner said in You know WPF, but do you know .Net Core?:

@Gribnit said in You know WPF, but do you know .Net Core?:
@Zenith said in You know WPF, but do you know .Net Core?:
@MrL said in You know WPF, but do you know .Net Core?:

That's Factory - you need to write instantiation code and worry about instances' lifecycle/state yourself.
namespace Zenith
{
  static class Factory
  {
    IObject GetIObject()
    {
      return new SomethingThatImplmentsIObject();
    }
  }
)
Oh no, I have to call a constructor.

I started with C++ and call Win32 in my C#, so I know all about pointers and references and marshaling and so on, and I never see any of that in modern development. Even the using keyword throws the "developers" on these jobs for a loop. My own patterns lean heavily towards static functions where by design I don't throw many objects with lifecycles around at all.

"Many" as in
You created dependency tree that is impossible to construct.
or
You forgot to register something in the container.

Another way of reading that is that you have the same two errors, and side effects of them, repeatedly. You know, like when JavaScript just stops executing because it has typos because it never ran through a compiler before deployment.
Ah, well, it's good that you now treasure your irrelevance.
In about a billion years, the sun will have gotten so hot that life on Earth as we know it will no longer be a thing, and given the intransigence of the "we shouldn't go to space until we've solved all our problems down here" crowd, along with their natural allies, the flat-earthers who contend that the Earth cannot be round because they cannot conceive of a round planet unless it's the size of Asteroid B612, the outlook does not look good for our species.

And in the much nearer term, can you find someone under 30 who isn't a film buff and knows who Clark Gable was? Irrelevance is fate.

So's death, but irrelevance is theoretically avoidable.

^{^{also yes. Film choreography students.}}

HardwareGeek

@Groaner said in You know WPF, but do you know .Net Core?:

can you find someone under 30 who ~~isn't a film buff and~~ knows who Clark Gable was?

Yes.

With the qualifier, I dunno, maybe. It depends on your definition of "film buff". My son doesn't consider himself a film buff, and my daughter probably even less so, but their taste in and knowledge of old movies and actors was greatly influenced by their mother and I, and we would probably fit comfortably within a reasonable definition.

Zenith

@Gribnit said in You know WPF, but do you know .Net Core?:

And then there's those that have finished learning.

Great choice of words, though surely not how you meant it.

Groaner

@HardwareGeek said in You know WPF, but do you know .Net Core?:

@Groaner said in You know WPF, but do you know .Net Core?:

can you find someone under 30 who ~~isn't a film buff and~~ knows who Clark Gable was?

Yes.

With the qualifier, I dunno, maybe. It depends on your definition of "film buff". My son doesn't consider himself a film buff, and my daughter probably even less so, but their taste in and knowledge of old movies and actors was greatly influenced by their mother and I, and we would probably fit comfortably within a reasonable definition.

Obviously my definition is going to be constructed in such a manner that I will always be right, and that singular examples do not lend themselves well to aggregate trends. That my hypothetical children might be able to recite Andrew Ryan's final monologue from memory doesn't speak much to the hypothetical cultural significance of Bioshock circa 2030. In fact, it might constitute evidence of child abuse.

Gribnit

@Zenith said in You know WPF, but do you know .Net Core?:

@Gribnit said in You know WPF, but do you know .Net Core?:

And then there's those that have finished learning.

Great choice of words, though surely not how you meant it.

If it was missing a "think" it was how I meant it.

Zenith

@Gribnit said in You know WPF, but do you know .Net Core?:

@Zenith said in You know WPF, but do you know .Net Core?:

@Gribnit said in You know WPF, but do you know .Net Core?:

And then there's those that have finished learning.

Great choice of words, though surely not how you meant it.

If it was missing a "think" it was how I meant it.

Upon learning all 26 letters, I finished learning the Roman alphabet. Multiplication, driving an automobile, Visual Basic syntax, the Gettysburg Address, how to program a VCR, all things that I "finished learning" long ago. It's hardly the pejorative that you're suggesting it is.

You want to masturbate to churning design pattern hype, go right ahead.

Gąska

@Groaner said in You know WPF, but do you know .Net Core?:

Obviously my definition is going to be constructed in such a manner that I will always be right

Bummer. At least you're still wrong about Intellisense.

Gribnit

@Zenith said in You know WPF, but do you know .Net Core?:

@Gribnit said in You know WPF, but do you know .Net Core?:

@Zenith said in You know WPF, but do you know .Net Core?:

@Gribnit said in You know WPF, but do you know .Net Core?:

And then there's those that have finished learning.

Great choice of words, though surely not how you meant it.

If it was missing a "think" it was how I meant it.

Upon learning all 26 letters, I finished learning the Roman alphabet. Multiplication, driving an automobile, Visual Basic syntax, the Gettysburg Address, how to program a VCR, all things that I "finished learning" long ago. It's hardly the pejorative that you're suggesting it is.

You want to masturbate to churning design pattern hype, go right ahead.

And hey, maybe some of those skills will retain value until you die.

MrL

@Zenith said in You know WPF, but do you know .Net Core?:

You want to masturbate to churning design pattern hype, go right ahead.

There's no hype for DI. I used it already 10 years ago. It's an obvious, mundane thing in places I work in.

BernieTheBernie

@PotatoEngineer said in You know WPF, but do you know .Net Core?:

I'd end up sticking these things into globals, and later, creating a global store of these dependencies to make it easier to get at them from awkward parts of code, and then... I've just reimplemented IoC, badly.

That looks more like "Service Locator". But sure: without a good framework, you likely end up at that

BernieTheBernie

@Jaime said in You know WPF, but do you know .Net Core?:

@PotatoEngineer said in You know WPF, but do you know .Net Core?:

(Granted, if you didn't prepare for a change, and you're suddenly forced, it's a much larger effort.)

If you did prepare, but didn't test every supported DB engine, then the effort is still large. If you did test every DB engine regularly, then you simply paid for the effort long before you needed it.

The only time I see multiple back-ends as useful is when you sell your product and a choice of back-ends will win more sales. However, it's always a good idea for the storage layer to be abstracted enough that the effort to support a new back-end is at least straightforward, even if significant.

At my previous employer, the database backend was originally Access, and the MS Sqlserver was added - that's very compatible this way round, only minor queries had differences.
Later on, we had to support Oracle because of some "invitation to tender" (that's why I am a member of the "I Hate Oracle Club"). That was a terrible lot of work, because Oracle is not compatible at all.
During that long work, I had to restructure all queries from plain text (!) queries to parameterized queries, and much more.
Though our sales team did not win, it was worth the effort: all database access was cleaned. Otherwise, you won't find the time to clean up those Augias Stables.

PleegWat

@BernieTheBernie Decades ago, I read a post somewhere telling people they should use unions instead of joins since some database engines don't support joins.

SQL just isn't compatible.

dkf

@PleegWat said in You know WPF, but do you know .Net Core?:

use unions instead of joins since some database engines don't support joins

I have unions of joins…

Zecc

@dkf As long as you don't join unions, which is not supported in American databases. </>

Kamil Podlesak

@PleegWat said in You know WPF, but do you know .Net Core?:

@BernieTheBernie Decades ago, I read a post somewhere telling people they should use unions instead of joins since some database engines don't support joins.

SQL just isn't compatible.

Wait, what? How do you replace JOIN with UNION? They are, like, almost exact opposite!

Kamil Podlesak

@Zecc said in You know WPF, but do you know .Net Core?:

@dkf As long as you don't join unions, which is not supported in American databases. </>

From what I've heard last year, it's definitely supported for police database. But those are full of suspect types anyway...

Grunnen

@topspin In C++ it is already a huge advantage to have "globals" that have an explicitly defined lifetime and are constructed and destructed in a determined order, compared to globals scattered around modules with indeterminate lifetimes, and core dumps if they depend on each other in a way that is incompatible with the construction/destruction order that the compiler thought out.

PleegWat

@Kamil-Podlesak said in You know WPF, but do you know .Net Core?:

@PleegWat said in You know WPF, but do you know .Net Core?:

@BernieTheBernie Decades ago, I read a post somewhere telling people they should use unions instead of joins since some database engines don't support joins.

SQL just isn't compatible.

Wait, what? How do you replace JOIN with UNION? They are, like, almost exact opposite!

That's how it was posed, and that was my reaction. I later found out they likely meant using unions of inner joints so you didn't have to use outer joins, but that was definitely not what they said the first time round.

And doesn't make much sense either. Though I do advice to only use left outer join, avoiding right and full outer joins, as IMO that can only lead to unreadable queries and probably isn't what you want.

boomzilla

@Groaner said in You know WPF, but do you know .Net Core?:

And in the much nearer term, can you find someone under 30 who isn't a film buff and knows who Clark Gable was?

Frankly @Groaner, I don't give a damn.

Kamil Podlesak

@PleegWat said in You know WPF, but do you know .Net Core?:

@Kamil-Podlesak said in You know WPF, but do you know .Net Core?:

@PleegWat said in You know WPF, but do you know .Net Core?:

@BernieTheBernie Decades ago, I read a post somewhere telling people they should use unions instead of joins since some database engines don't support joins.

SQL just isn't compatible.

Wait, what? How do you replace JOIN with UNION? They are, like, almost exact opposite!

That's how it was posed, and that was my reaction. I later found out they likely meant using unions of inner joints so you didn't have to use outer joins, but that was definitely not what they said the first time round.

And doesn't make much sense either. Though I do advice to only use left outer join, avoiding right and full outer joins, as IMO that can only lead to unreadable queries and probably isn't what you want.

Oh, full outer joins - I can see where they went. Although... I have never, ever heard about any valid use case for full outer join. Usually it's just a huge red flag signaling that the data model is completely borked.

boomzilla

@PleegWat said in You know WPF, but do you know .Net Core?:

Though I do advice to only use left outer join, avoiding right and full outer joins, as IMO that can only lead to unreadable queries and probably isn't what you want.

Yeah, I only use them in very rare circumstances.

PleegWat

@Kamil-Podlesak Indeed, I've heard of engines having trouble with right and full outer joins, and I don't think I've ever needed them. I do believe I have one or two unfiltered Cartesian products in there, though I'm unsure of where or why it was a good idea.

BernieTheBernie

@PleegWat said in You know WPF, but do you know .Net Core?:

unions of inner joints

Is it possible to smoke them?

Zenith

@Gribnit said in You know WPF, but do you know .Net Core?:

@Zenith said in You know WPF, but do you know .Net Core?:

@Gribnit said in You know WPF, but do you know .Net Core?:

@Zenith said in You know WPF, but do you know .Net Core?:

@Gribnit said in You know WPF, but do you know .Net Core?:

And then there's those that have finished learning.

Great choice of words, though surely not how you meant it.

If it was missing a "think" it was how I meant it.

Upon learning all 26 letters, I finished learning the Roman alphabet. Multiplication, driving an automobile, Visual Basic syntax, the Gettysburg Address, how to program a VCR, all things that I "finished learning" long ago. It's hardly the pejorative that you're suggesting it is.

You want to masturbate to churning design pattern hype, go right ahead.

And hey, maybe some of those skills will retain value until you die.

Reading is fundamental, you quack.

Zenith

@MrL said in You know WPF, but do you know .Net Core?:

Your projects are either simple enough that it makes sense, or horrible to work in.

A little from column A, a little from column B.

Any idiot can write a complicated system. Millions of JavaScript "developers" are a testament to that. It takes a great programmer to make complexity simple without losing functionality like the average developers does. Entire teams of contractors struggle, for years, to replace stuff that I've written. Some might even "finish" but guaranteed it'll do half as much at ten times the cost and require perpetual support. Very enterprisey though!

Gribnit

@Zenith said in You know WPF, but do you know .Net Core?:

@Gribnit said in You know WPF, but do you know .Net Core?:

@Zenith said in You know WPF, but do you know .Net Core?:

@Gribnit said in You know WPF, but do you know .Net Core?:

@Zenith said in You know WPF, but do you know .Net Core?:

@Gribnit said in You know WPF, but do you know .Net Core?:

And then there's those that have finished learning.

Great choice of words, though surely not how you meant it.

If it was missing a "think" it was how I meant it.

Upon learning all 26 letters, I finished learning the Roman alphabet. Multiplication, driving an automobile, Visual Basic syntax, the Gettysburg Address, how to program a VCR, all things that I "finished learning" long ago. It's hardly the pejorative that you're suggesting it is.

You want to masturbate to churning design pattern hype, go right ahead.

And hey, maybe some of those skills will retain value until you die.

Reading is fundamental, you quack.

Well good, you got at least 1 then. What is the market paying for literacy these days?

MrL

@Zenith said in You know WPF, but do you know .Net Core?:

@MrL said in You know WPF, but do you know .Net Core?:

Your projects are either simple enough that it makes sense, or horrible to work in.

A little from column A, a little from column B.

Any idiot can write a complicated system. Millions of JavaScript "developers" are a testament to that. It takes a great programmer to make complexity simple without losing functionality like the average developers does. Entire teams of contractors struggle, for years, to replace stuff that I've written. Some might even "finish" but guaranteed it'll do half as much at ten times the cost and require perpetual support.

That's great, but DI reduces complexity, so...