.NET Megathread 3.5: await GetGoodPosts()

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > .NET Megathread 3.5: await GetGoodPosts()

«‹›2 »

Destroyenator: Dec 27, 2004; Don't ask me lady, I live in beer

NihilCredo posted:

Well there is a community linter, it's integrated in the F# Power Tools. But I agree that an official MS style guide would make a much better impression on CTOs and assorted suits.

Ah nice, I wasn't aware of that. For us it's about getting a C# developer from another team comfortable with opening, reading and making small changes to an F# project. Your points about bundling the compiler, Power Tools and some decent templates in with the standard VS install are spot on.

# ¿ Aug 28, 2016 17:59

Adbot: ADBOT LOVES YOU

# ¿ May 22, 2024 18:33

Destroyenator: Dec 27, 2004; Don't ask me lady, I live in beer

amotea posted:

Something like this http://fsharp.org/specs/component-design-guidelines/ ?

I didn't know about that one, thanks!

spiderlemur posted:

Kind of a separate question: Is there any point to integration tests (and/or using poo poo like Selenium), or can everything more or less be covered with good unit testing?

In a perfect world I see myself creating a mock repository, creating my controller and injecting it that repository, then see what comes out of the other end by inspecting the ViewData on the Controller properties.

If you're just newing up the controller you don't have any guarantees that the app will successfully start up, routing, injection, model binding or anything else in the pipeline will do as you expect.

This post is little old but is still very doable and I think aspnet core is going to encourage more of this: https://blogs.msdn.microsoft.com/webdev/2013/11/26/unit-testing-owin-applications-using-testserver/

Setup the first time is a little trickier because you have to work out how to manage injecting your mocks and stuff, but I think it can be a useful midway point between simple controller tests and full blown UI tests.

# ¿ Aug 30, 2016 16:00

Destroyenator: Dec 27, 2004; Don't ask me lady, I live in beer

How you want to deal with one or more network requests failing also matters.

# ¿ Oct 28, 2016 21:03

Destroyenator: Dec 27, 2004; Don't ask me lady, I live in beer

chippy posted:

I'm curious about this - I've never really looked deeply into the SQL that gets generated, other than a quick glance out of curiosity. It did look pretty terrible. Is there a reason that it can't be optimised into a decent execution plan? I always thought that due to SQL being declarative rather than imperative, a bunch of lovely SQL vs a some good SQL that did the same thing as the lovely SQL, would basically be optimised and end up with pretty much the same execution plan? Is this not the cause? Or does EF just generate such monstrous queries that the optimiser can't do much with it?

MiniProfiler is pretty good for checking this sort of thing out, I think it even turns up red when you make N+1 calls. I've heard good things about Glimpse too but I haven't used it myself.

# ¿ Dec 6, 2016 20:35

Destroyenator: Dec 27, 2004; Don't ask me lady, I live in beer

You can also do it anonymous types if you don't want to write a class.

code:

var thing = JsonConvert.DeserializeAnonymousType(json, new { Header = new { SimpleStringHeader = "" }});
var simple = thing.Header.SimpleStringHeader;

# ¿ Jan 2, 2017 14:38

Destroyenator: Dec 27, 2004; Don't ask me lady, I live in beer

chippy posted:

Thoughts on the Unit Of Work/Repository pattern? I'm considering implementing repositories to use in my service layer, mostly to assist with unit testing/mocking, but as the UoW pattern's primary use seems to be to make sure the repos all use the same context, this seems redundant as I'm using Autofac to inject my context with an instance-per-request lifetime.

For a solo project that's mostly CRUD I'd start with Linq against a context, as soon as it gets too painful to test or you're doing much more than "SingleOrDefault(u => u.id == id)" I'd switch to repositories. If you stick to fairly straightforward CRUD repositories can be fine, even if it's just a way to have descriptive method names for your common queries.

If you find you're adding more specific or complex domain methods to the repos then it's a sign you could switch a cqrs like model.

If you want to try that you don't have to go all in with a framework for it, there's nothing wrong with starting with something like this:

code:

public class UpdateBillingDetails
{
    private readonly Guid _userId;
    private readonly Details _details;
    ctor(Guid userId, Details details)
     {
        _u = u;
        _d = d;
    }

    public Task Handle(IDbConnection conn)
    {
        //whatever
    }
}

New these up in the controllers and use an injected connection. For testing just use a mock connection. If that gets too messy or you want more structure than something like that Mediator mentioned above is probably decent. I'd just be hesitant to throw too many infrastructure pieces at a project until you're underway and have started hitting some of the problems they solve.

If there's a team working on a new project in a professional context you want a bit more forward planning but this is for your studies, right?

# ¿ Mar 9, 2017 22:51

Destroyenator: Dec 27, 2004; Don't ask me lady, I live in beer

Most C# coding standards mandate one class per file, it's usually a good rule until it isn't. For code like that I'd put all your generated classes in a separate file because they are "different" sort of code that should be separate from your logic, but not move them out to individual files per class because they are so closely interlinked and if you want to regenerate them it's all in one place.

Really it's a per-taste thing, the compiler doesn't care.

# ¿ Mar 16, 2017 23:46

Destroyenator: Dec 27, 2004; Don't ask me lady, I live in beer

Munkeymon posted:

ASP still won't route something that looks like a number to {*url} though. I hate the way ASP does routing

e: Really anything in .Net that's run-it-and-see-if-it-works is maddening because that's what a compiler is supposed to be for

If you can deal with the fiddly setup, using the ASP TestServer stuff can be really nice for sorting out these issues. For pre-core stuff you have to set the project up as an OWIN thing (slightly different configure signature but it still runs on IIS) and it can take a little while to get all the right packages in place but it essentially creates an in-memory server and gives you an HttpClient pointing at it. You call into the Configure step so set up whatever mocks for DI and then you get fast, isolated, tests of your app including routing, deserialisation and filters.

I haven't bothered with the setup on many projects but I think it's worthwhile spending the time on big enough ones. We've caught some tricky deserialisation problems with it and it's great to have instant turnaround on route conflicts etc.

# ¿ Jun 13, 2017 22:19

Destroyenator: Dec 27, 2004; Don't ask me lady, I live in beer

sausage king of Chicago posted:

so i'm using Masstransit and RabbitMQ for messaging and running into a problem which i'm going to try to badly explain. there's a common assembly that a bunch of services use to dispatch events that looks like this:

it's using a singleton pattern so only one connection per app is open at a time. the issue is that once the bus is started and an event is published, the connection never closes, which is leading to some problems, obviously, and I'm not sure how to handle this or how to rework the code to fit this model so everything referencing it doesn't need to be changed.

there are a ton of events that could happen, so having one connection open to handle them was the decision that was made instead of opening a new connection each time an event needs to be published. i tried implementing a dispose method, but since you have to call it manually, that really doesn't work in this case. any ideas on how to handle this?

If I understand correctly you want to close the connection when there's nothing to send? You could try something like this:

code:


public class EventSender
    {
        private readonly TimeSpan _idleTime;
        private readonly BlockingCollection<Tuple<TaskCompletionSource<bool>, object[]>> _queue;
        private readonly Thread _thread;

        public EventSender(TimeSpan idleTime)
        {
            _idleTime = idleTime;
            _queue = new BlockingCollection<Tuple<TaskCompletionSource<bool>, object[]>>();
            _thread = new Thread(Consume) { IsBackground = true };
        }

        public async Task<bool> Send(object[] items)
        {
            var tcs = new TaskCompletionSource<bool>();
            _queue.Add(Tuple.Create(tcs, items));
            return await tcs.Task;
        }

        private void Consume()
        {
            while (true)
            {
                try
                {
                    var currentItem = _queue.Take();

                    // bus open

                    do
                    {
                        var items = currentItem.Item2;
                        var completionSignal = currentItem.Item1;

                        foreach (var item in items)
                        {
                            // bus send
                        }

                        completionSignal.SetResult(true);

                    } while (_queue.TryTake(out currentItem, _idleTime));

                }
                finally
                {
                    // bus close
                }
            }
        }
    }

(note: entirely untested, and you probably want to think about the error handling paths and maybe passing exceptions back in the task completion source)

Edit: actually yeah you definitely need to catch opening/sending exceptions and set them on the tcs or the callers will never return on error.

Destroyenator fucked around with this message at 08:14 on Aug 25, 2017

# ¿ Aug 25, 2017 08:05

Destroyenator: Dec 27, 2004; Don't ask me lady, I live in beer

Munkeymon posted:

I was reading https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/ and it occoured to me that the Chrome (and probably FF?) debuggers do something I really appreciate when I'm at a breakpoint where they just display all of the locals inline instead of making me hover over individual elements or futz with the panels to see the values. Is there an extension that does that? If not, am I the only one interested in such a thing?

If by "futz with panels" you mean the "Watch" window then you should check out the "Autos" window. Still a panel but it's usually pretty good at picking which variables you'd care about without touching it.

# ¿ Oct 5, 2017 18:29

Destroyenator: Dec 27, 2004; Don't ask me lady, I live in beer

They can do entity tracking so when different part of your codebase ask for Car id 7 they get the same in memory object. They can also do change tracking so when you modify that object you can then do a "save" style operation which will generate an appropriate UPDATE rather than a full overwrite.

Sometimes these are good features, sometimes not.

edit: the change tracking can also involve adding or removing from list properties on the object where they make sure the linked item is inserted or deleted and foreign keys all work out etc.

Destroyenator fucked around with this message at 22:43 on Oct 31, 2017

# ¿ Oct 31, 2017 22:41

Adbot: ADBOT LOVES YOU

# ¿ May 22, 2024 18:33

Destroyenator: Dec 27, 2004; Don't ask me lady, I live in beer

Portland Sucks posted:

More to the point I think the reason why I struggle with seeing how an ORM could fit into our existing process is because it seems like ORMs rely on conforming to some kind of baseline with regards to how your backend is structured and ours is literally chaos (they call it "flexibility").

ORMs are designed for persisting and retrieving Objects in the OO sense (think the classic Order has a Customer and a list of LineItems). If the data you have isn't structured that way or you don't interact with it in code as proper domain modelled Objects then ORMs will always be a bad fit. That doesn't mean the code is necessarily wrong it's just that an ORM isn't the right tool for the abstractions you're using.

# ¿ Nov 1, 2017 21:42

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > .NET Megathread 3.5: await GetGoodPosts()

«‹›2 »