Attention: We are retiring the ASP.NET Community Blogs. Learn more >

Frans Bouma's blog

The blog of Frans Bouma, creator and lead developer of LLBLGen Pro and ORM Profiler.

  • from el in world.ExtensionMethodsLibraries group el by el.Method into g select g;

    Everyone who's doing .NET 3.5 development these days will likely run into the same problem I ran into this morning: your set of extension methods grows beyond the level of a single file and you need to group them into separate sets of files or worse: you discover you have several distinct projects which all have extension methods and it's better to group them into a single library.

  • Is BDUF really BDUF?

    Justing Etheredge posted a great article about that Design Up Front (DUF) is something else than Big Design Up Front (BDUF). He discusses the misunderstanding that just because BDUF is considered harmful in a lot of projects, it's not said that DUF is too and one should just jump in, start hammering in code and hope for the best. As an example of BDUF, Justin uses the example of a car manufacturer and asks himself why a car manufacturer uses BDUF (according to Justin) and we in software land often don't or at least try to avoid it.

  • Software Patents are evil, here's why

    I was looking for a reference in ADO.NET Entity Framework documentation (via Google) if a Complex type in an EDM could be part of an association (relationship) like Hibernate supports. I needed this for some tool I'm working on . Google gave me an interesting link, namely to a patent held by MS about relationshipsets in the EDM. It refers to other patents of similar straight-forward concepts, either based on stuff defined by Codd or defined by other O/R mapper frameworks like Hibernate or Toplink long before the filing took place. Why these common concepts are even patentable (as they're discoveries in math-space, so not really inventions) is beyond me.

  • "The Entity Data Model is much bigger than just an ORM" -- Stephen Forte

    With almost bleeding ears I'm currently listening to show #369 of .NET Rocks!, which has Danny Simmons and Stephen Forte as guests. Danny is of course known of his major role in the Entity Framework (EF) design and Forte is one of the Council of Wise Men (TM) which are advising the EF team how to make the EF a better product / system / whatever.

  • The evil of the Office UI ribbon license

    For the next major version of a certain application I'm working on (gee, what might that be ) I'm researching some UI frameworks and techniques. In the past few months I've spend most of my time working on application support library code, language designs, algorithm design etc. etc. (more on that in a later article) and I arrived at the point where I wanted to see how my vision for the major version would work in a draft application, just to see how the various elements would work together visually.

    One of the first questions one would ask these days when a new desktop application is started is: WPF or Winforms? The current version is build with Winforms all the way though it's tempting to go for WPF, as it's new, has nice performance and great looks (if you're able to cook up the styles). After a day or 2 of fiddling with the various WPF docking frameworks out there, there's one firm conclusion to be drawn: WPF isn't up to par with Winforms when it comes to serious applications which use a normal windows look and feel: automatic menu, buttonbar handling based on selected docked window for example, one of the cool features of many winforms control libraries, is one of those things which is hard to do in WPF (at least, it's not directly available/build in). One other thing which made me draw the above conclusion was that it in general sucks bigtime when you have a normal windows application with normal menus: the text is in general blurry (or at least blurry in a short period of time after a move/open) and to make the menus to look like normal menus like in VS.NET is a pain (it doesn't get close).

    Because we will need a custom rendering system in this major version for some areas, we do need WPF. However, one can host a WPF control just fine in a winforms application, so re-using our already written winforms skeleton was a choice I didn't expect at first but which makes sense.

  • Linq to LLBLGen Pro: feature highlights, part 2

    In the first part of this series I talked about the fact that Linq to LLBLGen Pro is a full implementation of Linq and why it's so important to use a full linq provider instead of a half-baked one. Today, I'll discuss a couple of native LLBLGen Pro features we've added to our Linq provider via extension methods: hierarchical fetches and exclusion of entity fields in a query. Furthermore some other features will be in the spotlight as well. What I also want to highlight is that using an O/R mapper is more than just filling dumb classes with dumb data: it's entity management, and the O/R mapper framework should offer you tools so you will be able to manage and do whatever you want with the entity graph in memory with as less problems and friction as possible. After all, the task you have isn't writing infrastructure code, entity classes nor code to make these interact with eachother, your task is to write code which consumes these classes, and works with these classes. This thus means that you should be able to work on that code from the get-go, as that's what your client expects from you .

  • Email form disabled again...

    I've again disabled the email form on this blog, because I now get about 15 spam emails every 5 minutes through this form and enough is enough. Apparently it's not fixable by the blog-engine overloads, so this is the only option. If you want to contact me, my email address is on the about page.

  • Linq to LLBLGen Pro: feature highlights, part 1

    Some people asked me what the highlights are of Linq to LLBLGen Pro, which was released this week, as it seems that Linq support is apparently growing on trees these days. In this and some future posts I'll try to sum up some of the characteristic features of Linq to LLBLGen Pro, so you don't have to wade through the 15 articles I wrote about writing Linq to LLBLGen Pro . I'll write several of these articles, this is the first one. I hope to write more of them in the coming weeks.