Let's say in my domain I have a Money(amount, Currency(name)) value object (for example: new Money(1000, new Currency('USD'))).
However in my presentation layer (and only there really) I don't want to use USD currency name, but symbol ($) instead.
I don't want to overload my value object with presentation properties (since besides symbol there can be also such things as placement).
How do you guys handle this kind of mappings? Should I create some kind of CurrencyPropertyInMemoryRepository and fetch all info from there? What are my options?
I understand your concern that you want to separate this presentation aspect from your domain data, and if you want to go that way, I think using a repository for mapping the currency name to its symbol might be a good solution (retrieving the correct symbol could then be done in a ValueConverter for example that transforms your model data before they are presented in your UI).
But I personally would not have an issue by storing this additional symbol information also in the currency value object, for two reasons:
The currency symbol is highly related to the currency itself, so whenever the currency name changes, the symbol might also change. Therefore it would make sense to have both information stored in the same place or at least quite close to each other. When using an additional repository, your information is spread at least over two places.
If you have both information within your value object, you could also put additional behavior in your value object (e.g. not every currency has a symbol, in that case you need some logic to decide what to print instead).
Related
I have a table named buildings
each building has zero - n images
I have two solutions
the first one (the classic solution) using two tables:
buildings(id, name, address)
building_images(id, building_id, image_url)
and the second solution using olny one table
buildings(id, name, address, image_urls_csv)
Given I won't need to search by image URL obviously,
I think the second solution (using image_urls_csv column) is easier to use, and no need to create another table just to keep the images, also I will avoid the hassle of multiple queries or joining.
the question is, if I don't really want to filter, search or group by the filed value, can I just make it CSV?
On the one hand, by simply having a column of image_urls_list avoids joins or multiple queries, yes. A single round-trip to the db is always a plus.
On the other hand, you then have a string of urls that you need to parse. What happens when a URL has a comma in it? Oh, I know, you quote it. But now you need a parser that is beyond a simple naive split on commas. And then, three months from now, someone will ask you which buildings share a given image, and you'll go through contortions to handle quotes, not-quotes, and entries that are at the beginning or end of the string (and thus don't have commas on either side). You'll start writing some SQL to handle all this and then say to heck with it all and push it up to your higher-level language to parse each entry and tell if a given image is in there, and find that this is slow, although you'll realise that you can at least look for %<url>% to limit it, ... and now you've spent more time trying to hack around your performance improvement of putting everything into a single entry than you saved by avoiding joins.
A year later, someone will give you a building with so many URLs that it overflows the text limit you put in for that field, breaking the whole thing. Or add some extra fields to each for extra metadata ("last updated", "expires", ...).
So, yes, you absolutely can put in a list of URLs here. And if this is postgres or any other db that has arrays as a first-class field type, that may be okay. But do yourself a favour, and keep them separate. It's a moderate amount of up-front pain, and the long-term gain is probably going to make you very happy you did.
Not
"Given I won't need to search by image URL obviously" is an assumption that you cannot make about a database. Even if you never do end up searching by url, you might add other attributes of building images, such as titles, alt tags, width, height, etc, so you would end up having to serialize all this data in that one column, and then you would not be able to index any of it. Plus, if you serialize it with one language, then you or whoever comes after you using a different language will either have to install some 3rd party library to deserialize your stuff or write their own deserialization function.
The only case that I can think of where you should keep serialized data in a database is when you inherit old software that you don't have time to fix yet.
I'm working with threedimensional arrays and it would be neat if I could name the array dimensions. The question marks in the example below are giving me the idea that this is possible.
Is it, and if so, how does it work? I can't seem to find it anywhere.
The three question marks are showing you that this array has three dimensions. If there was only one question mark, it would mean that the variable was declared as one dimensional. This is built in to VB and can't be change, as far as I know.
I think there's real value into making your code more readable and self-documenting. If I had a three dim array, I would probably create some custom class modules to model the objects that I was using.
If your first dimension is a SchoolID, your second dimension is a ClassID, and your third dimension is a StudentID, then code using custom class modules like this
Debug.Print Schools(10).Classes(3).Students(7).Name
is more readable than
Debug.Print arrLeeftijdenG5(10,3,7)
I don't know what you're storing, so it's just an example. Consider using custom class module to model the real-world objects your code is manipulating. There's a bit more set up involved, but it pays dividends down the road.
I'm using EF code first with a fairly large number of entity types and I am building a number of reports with filter models that refer to the ID (primary key) fields in the different entity types. Depending on the table, the ID field is either a Byte, Short, Integer or Long (depending on how many records I expect in that table and where it is referenced from).
Eg. I may have a "Channel" table which has an ID field of type Short, whereas "Order" has an ID field of type "Integer".
When I create a model for a view to filter on eg. Channel, I would do a ChannelID Property, which would either be a Short or a Short? (as in Nullable(Of Short)). However, this is a pain as I have to look up the correct ID type for the relevant entity type each time I add a filter and in the long run, it is fragile as I may change the ID type on a particular entity and don't want to have to hunt down every reference to it.
Ideally, I would like to have some way of referring to it eg.
Public Property ChannelID As TypeOf([Channel].[ID])
but I can't see any way to do that.
If I was using C, I would probably #define ChannelID short and just refer to the type as ChannelID throughout, but I can't see any way of using the VB.NET compiler to achieve something like that (which isn't quite as good as the above solution either.
I have thought of the idea of implementing it as an interface for each type, but that doesn't work if there are multiple properties filtering on the same entity in a single model (which is possible), and it is messy as it means an interface for every entity type.
I realise that I could just set them all as Long and there isn't really a major disadvantage to doing this, but I am picky about matching types.
Does anyone have any clever ideas for dealing with this?
Type aliasing will work across files - set this on the 'References' tab of the project properties - e.g., test = System.Int32.
Then in any file in the project you can use the type alias 'test'.
e.g.,
Dim myInt As test
Only my second stack question, I'm pretty new to ssrs, but I'd rather do it the right way and learn now, then have to come back and fix everything later.
I'm going to create a semi-flexible reporting (SSRS) standard for my company and getting global consensus ahead of time is impossible. My proposed solution will be to create a formatting table that I can update to alter the look and feel of all my reports of one type. (tables, charts etc.) I have thought of two ways to do this and I am looking for advice on which is better and if how I am thinking it will work...will actually work. I am totally willing to research all the specifics of how-to, but I'd really appreciate a hint on how to start.
Is there a way to reference which attribute (e.g. name, background color) your expression is in? It would be awesome if I could use the same code for all the attribute's expressions and just have that code find it's spot in the table.
something like:
attribute.value = lookup(ReportFormataDataset as RFD, attribute.name =
RFD.name and left(me.name, 3) = RFD.prefix)
Alternatively I could run a loop in VBA code to change the attributes based on what's in the table. I plan to create a report template with naming conventions to help. (e.g. hdr, ttl, bdy prefix) so it could look like:
for each reportItem in report
for each el in FormatTable
'make sure the report item is what I think it is, like header
if left(ReportItem.name, 3) = el.prefix then
'e.g. backgroundcolor = Blue
name.value = el.value
end if
end loop
end loop
but then when would I run it, I would imagine this slowing my report a lot if I did this in the expressions. Maybe with variables instead?
I found this:
tips-tricks-ensure-consistency-sql-server-reporting-services-reports
but it seems very cumbersome to maintain if I add a formatting requirement later I'll have to add that parameter to all the reports and the attribute.
I know this seems a little fishing-y but I am not sure how either of these would work and I know I could throw days of effort at either when an expert could point me in the right direction in 5 minutes so... sorry if this is not in the 'stack spirit' and thank you.
We have implemented something similar, and have used the method of setting up a shared dataset that all the reports call. This returns a single record, that includes all the images, background colours and date formats we might use across the reports (including company logo and branding colours).
If we had a date in a cell for example, we would then set the number format to
=First(Fields!FullDateFormat.Value, "ReportConstants")
Where ReportConstants is the named of the shared dataset.
This also allows us to have the same report deployed both in the UK and the US, yet both use their native date format, as this is set by the database instance, instead of within the report.
Now whether this is the right approach to take or not is another question, but it works for us, using the ~50 reports in multiple locations, without having to configure each one individually all the time.
Is this helpful?
I'm currently working on a site that sells products of varying types that are custom manufactured. I've got your general, standard cart schema: Order has many LineItems, LineItems have one Product, but I've run into a bit of a sticking point:
Lets say one of our products is a ball, and one of our products is a box of crayons. While people are creating their order, we end up creating items that could be represented by some psuedocode:
Ball:
attributes:
diameter: decimal
color: foreign_ref_to Colors.id
material: foreign_ref to Materials.id
CrayonBox:
attributes:
width: decimal
height: decimal
front_text: string
crayons: many_to_many with Crayon
...
Now, these are created and stored in our db before an order is made. I can pretty easily make it so that when an item is added to a cart, we get a product name and price by doing the linking from Ball or CrayonBox in my controller and generating the LineItem, but it would be nice if we could provide a full set of info for every line item.
I've thought of a few possible solutions, but none that seem ideal:
One: use an intermediary "product info" linking table, and represent different products in terms of that, so we'd have something like:
LineItem
information: many_to_many with product_information
...
ProductInformation:
lineitem: many_to_many with line_item
name: string
value: string
ProductInformation(name='color', value=$SOMECOLOR)
ProductInformation(name='color', value=$SOMEOTHERCOLOR)
...
The problem with this is that the types of data needed to be represented for each attribute of a product does not all fall under the same column type. I could represent everything with strings, but $DEITY knows I don't even come close to thinking that's a good solution.
The other solution I've thought of is having the LineItem table have a foreign key to each table that represents a Product type. Unfortunately, this means I would have to check for the existence of each foreign key in my controller. I don't like this very much at all, but I like it marginally better than stuffing every piece of data into one datatype and then dealing with all the conversion stuff outside of the DB.
One other possible solution would be to store the tablename of the product data in a column, but that can't possibly be a good thing to do, can it? I lose the capability of the db to link stuff together, and it strikes me as akin to using eval() where it's not needed -- and we all know that eval() isn't really needed very often.
I want to be able to say "give me the line item, and then the extended info for that line item", and have the correct set of information for various product types.
So, people who actually know what they're doing with database schema, what should I be doing? How should I be representing this? This seems like it would be a fairly common use case, but I haven't been able to find much info with googling -- is there a common pattern for things like this? Need more info? This can't possibly be outside of the realm of "you can use a RDBMS for this", can it?
Edit: I'm now fairly certain that what I want here is Class Table Inheritance. with an alias in my individual models to "normalize" the link followed to the "info" table for each product type. Unfortunately, the ORM I'm kinda stuck using for this (Doctrine 1.2) doesn't support Class Table Inheritance. I may be able to accomplish something similar with Doctrine's "column aggregation" inheritance, but egh. Anyone think I'm barking way up the wrong tree? I looked over EAV, and I don't think it quite fits the problem -- each set of information about different products is known, although they might be very different from product type A to product type B. The flexibility of EAV may be nice, but it seems like an abuse of the db for a problem like this.
It strikes me that this is a perfect fit for the likes of CouchDB / MongoDB which allow every 'row' to contain different attributes, yet permits indexed lookups. It should be fairly straightforward to build a hybrid structure using MySQL for the rigid relational parts and 'nosql' for the parts of varying shape.
Take a look at this discussion.
Assumptions:
You have some specific products you're selling. I.e., you know you're selling crayons, but not spatulas. The customer doesn't come to your site and try to order a product you've never heard of.
The products you're selling have a pre-existing set of attributes. I.e., crayons have color; crayon_boxes have width, height, crayons... The customer doesn't come to your site and try to specify the value for an attribute you've never heard of.
One way to do this (if you're a RBDM purist, please close your eyes now until I tell you to open them again) is to use an attribute string. So the table would be like this:
Products
+ ProductName
+ ProductAttribute
And then a sample record would be like this:
Product Name = "Crayon Box"
Product Attribute = "Height:5 inches;Width:7 inches"
With something like this, parse the name/value pairs in or out as necessary.