I am going to use subsonic 3 in a large enterprise winform application.
what i saw in my personal tests is that subsonic cannot handle complex type references well.
for example if we have an ADDRESS complex type in PERSON object , as far as i saw subsonic just created the PERSON table and is not caring about the Address property of it !
i was wondering how can i solve it ?
Secondly, we have inheritance in our objects, how subsonic can handle it with table-per-subclass strategy?
SubSonic isn't well suited to these scenarios. Regarding complex types you could write a service/repository to handle saving and building these types, but there's no pre-existing way of mapping this to the database.
The same goes for inheritance schemes.
You might want to look at more full-featured O/RM like NHibernate or EF.
Related
I am developing Library Management System which have two sorts of books (Ebook and PrintedBook).
I intends to make search capacity with both ebook and printedbook in the same page.
The only problem is that I see that ebook and printedbook are book. And should I make an Book entity, and PrintedBook and Ebook inherits Book entity. If I do this, the search capacity is easier by using IBookRepository. If not I have to join two tables (Ebooks and PrintedBooks).
Please help me.
Dealing with inheritance at persistance level, esspecialy when talking about relation databases, can be a headache. First of all you should ask yourself why is this a problem for you.
If the problem is a performance due to using JOIN in you database query you might look at technique called single table inheritance. Basically you have one table containing all the columns of all your book types (i.e. PrintedBook and Ebook). This way you don't have to use JOIN, but you sacrifice some storage.
Other then the concrete table inheritanec technique (as described by yourself) there is no other way how to deal with the inheritance problem in relation databases.
If your application becomes too complex or the domain model isn't compatible with your read use cases, you might look at read-model. Read-model helps you to focus on your problem domain without modifying it while having easy access to the data. This is very complex topic so if you want to read something about read-models (or about DDD implementation problems/techniques) I recommend you to read Implementing Domain-Driven Design by Vaugh Vernon.
I'm facing several problems trying to apply DDD with EF4 (in ASP MVC2 context). Your advaice would be greatly appreciated.
First of all, I started to use POCO because the dependacy on ObjectContext was not very comfortable in many situations.
Going to POCO solved some problems but the experience is not what I was used to with NHibernate.
I would like to know if it's possible to use designer and to generate not only entities but also a Value Objects (ComplexType?). If I mean Value Object is a class with one ctor without any set properties (T4 modification needed ?).
The only way I found to add behavior to anemic entities is to create partial classes that extends those generated by edmx. I'm not satisfied with this approach.
I don't know how to create several repositories with one edmx. For now I'm using a partial classes to group methods for each aggregate. Each group is a repository in fact.
The last question is about IQueryable. Should it be exposed outside the repository ? If I refer to the ble book, the repository should be a unit of execution and shouldn't expose something like IQueryable. What do you think ?
Thanks for your help.
Thomas
It's fine to use POCOs, but note that EntityObject doesn't require an ObjectContext.
Yes, Complex Types are value objects and yes, you can generate them in the designer. Select several properties of an entity, right click, and choose refactor into complex type.
I strongly recommend putting business methods in their own types, not on entities. "Anemic" types can be a problem if you must maintain them, but when they're codegened they're hardly a maintenance problem. Making business logic separate from entity types allows your business rules and your data model to evolve independently. Yes, you must use partial classes if you must mix these concerns, but I don't believe that separating your model and your rules is a bad thing.
I think that repositories should expose IQueryable, but you can make a good case that domain services should not. People often try to build their repositories into domain services, but remember that the repository exists only to abstract away persistence. Concerns like security should be in domain services, and you can make the case that having IQueryable there gives too much power to the consumer.
I think it's OK to expose IQueryable outside of the repository, only because not doing so could be unnecessarily restrictive. If you only expose data via methods like GetPeopleByBirthday and GetPeopleByLastName, what happens when somebody goes to search for a person by last name and birthday? Do you pull in all the people with the last name "Smith" and do a linear search for the birthday you want, or do you create a new method GetPeopleByBirthdayAndLastName? What about the poor hapless fellow who has to implement a QBE form?
Back when the only way to make ad hoc queries against the domain was to generate SQL, the only way to keep yourself safe was to offer just specific methods to retrieve and change data. Now that we have LINQ, though, there's no reason to keep the handcuffs on. Anybody can submit a query and you can execute it safely without concern.
Of course, you could be concerned that a user might be able to view another's data, but that's easy to mitigate because you can restrict what data you give out. For example:
public IQueryable<Content> Content
{
get { return Content.Where(c => c.UserId == this.UserId); }
}
This will make sure that the only Content rows that the user can get are those that have his UserId.
If your concern is the load on the database, you could do things like examine query expressions for table scans (accessing tables without Where clauses or with no indexed columns in the Where clause). Granted, that's non-trivial, and I wouldn't recommend it.
It's been some time since I asked that question and had a chance to do it on my own.
I don't think it's a good practice to expose IQueryable at all outside the DAL layer. It brings more problems that it solves. I'm talking about large MVC applications. First of all the refactorings is harder, many developers user IQueryable instances from the views and after struggle with the fact that when resolving IQueryable the connection was already disposed. Performance problems because all the database is often queried for a given set of resultats and so on.
I rather expose Ienumerable from my repositories and believe me, it saves me many troubles.
Im new to subsonic and generally this was of programming, i usually develop from a rad perspective so using the visual studio dataset designer, but i wanted to start looking at developing n teir approach.
Ive never used a business logic layer, (naughy) normally my code behind takes care of validation so to speak aswell as general page level validation.
How can i generate my business logic, do i create a partial class of one of my classes and then add the business logic into this? and how would this look? just so i have an idea.
Any exmaples or advice would be greatly appreciated.
Thanks
Dan
The big gotchya with SubSonic is that it generates classes from database tables, there is a 1-to-1 correspondence between the two. That makes the classes SubSonic generates quite unsuitable for use as business objects, because it would tie your business layer very directly to your database structure. This is a bad thing (in nearly all scenarios that come to my mind, anyway).
SubSonic is a query tool and little more. It most certainly is not an ORM.
With that in mind, I believe the correct way to create a Business Logic Layer is to write your own business classes, and write Repository classes to manage loading and storing the data. But use SubSonic only internally to the Repository classes to handle the actual persisting of your data to the database.
If you use the SubSonic generated classes throughout your project you will find you are most likely doing it wrong, and the first significant change to your DB schema will illustrate that nicely (or .. not nicely).
In fact, I would recommend quickly moving into learning a real ORM like NHibernate or Entity Framework. They bring you much farther down the Happy Path, whereas SubSonic still requires one to do much of the Data Layer implementation themselves.
Is anyone aware of a vendor neutral XSD to describe a relational database schema? Our system needs to grab information about the structure of a database:
Tables
Columns and types
Primary and Foreign Keys Constraints
Indexes
etc
in a vendor independent manner and store it in an XML file for later processing.
Before we do what we typically do and roll our own. I wanted to do some research and see if there was an existing XSD that people are standardizing on for what I assume is not an uncommon requirement for modeling tools and such. I did not find anything on Google that was not database vendor specific. If you know of an existing public standard I would very much appreciate a link.
Thanks in advance,
Terence
This isn't exactly what you're looking for, but the PostgresSQL Wiki has an interesting section on XML exports, that describes how they are supporting SQL and XML together. It displays a section on how a table would be exported as as XML and the XSD that would support it, which looks rather generic. It could serve as a model for you to create your own.
The Wiki talks about reference to a ISO/IEC 9075-14:2006 standard, that appears to be adopted by a few big vendors as a baseline. I quick browse on the ISO site says that :2006 was updated to 2008. I'm sure you can find a covered spec of this that you don't have to pay for to download.
The article also points to a SQL/XML standard definition that is a bit outdated, but could serve your needs if you're looking for some basics.
Interesting problem - I am not aware of any standard or tool to achieve this.
You would almost have to have some kind of a "neutralized" version with adapters for each individual database system you want to target - even just to map all the various data types (VARCHAR and NVARCHAR in SQL Server, VARCHAR2 in Oracle and so on).
You might just use the types defined in the SQL:2003 standard - but even then you'd probably still have to have some kind of a vendor-specific mapping / adaption of sorts. Not to mention some kind of support for vendor-specific implementation details (like IDENTITY columns in SQL Server vs. SEQUENCE in Oracle and others).
Very interesting question! I hope others will be able to shed more light on the issue and maybe recommend an existing tool.
If not, and you decide to roll your own - consider making it open-source on CodePlex or Google Code! I'm sure a lot of folks would be most interested!
MArc
The UML Information Management Metamodel (IMM) Specification from OMG may worth a try.
This is an embarrassingly basic n-tier question.
I've created a DAL project in VS2008 with subsonic. It's got a widget class, a widgetcollection class, and a widgetcontroller class.
I've created my Business logic project (no I can't put it in the same tier) that references it. Using certain business criteria, it selects a collection of widgets in a function that returns a widgetcollection.
My question is: how does my GUI layer bind the collection to a grid? I know that the widgetcollection is a valid datasource for a datagrid, but how does the GUI layer know what a widget and widgetcollection are? Surely I don't have to reference the DAL from the GUI, that negates the whole point.
Firstly, I dont think this is an embarrasingly basic n-tier question.
It is a very interesting subject and one I attempted to stimulate discussion for in the old Subsonic Forums.
I share your reluctance to expose my GUI layer to the DAL.
My GUI layer only talks to BLL using the vocabulary and topics of my own Entity Model and only returns my own entities or lists or in some cases Data Tables.
My BLL only talks to a MAPping layer which maps Fetches,Saves etc to the appropriate DAL CRUD methods and converts the returned Subsonic types to my Entity types.
In doing this I was suprised at how much of Subsonic I had to duplicate and at times I felt I was going down the wrong road, I am feeling more comfortable with it now, though it still needs refactoring and refining.
For example, finding a flexible, generic means of indicating to my BLL which row(s) I wanted returned in a fetch was a challenge I hadn't expected and I finished up writing a generic queryClass with fluent interface which looks a lot like a Subsonic Select.
FWIW, I think you are headed down the right track, I guess what you have to do though is decide how you want to define those Subsonic types to your GUI.
Rob has an interesting discussion you may be interested in.
(using SubSonic 2.x) In my BLL classes I have a property which gives an object reference to the relevant DAL class. My UI form has a reference to the BLL class, so from the form I can address the DAL properties and methods via .BLL.DAL.xxxx
FWIW, I have never managed to successfully bind a SubSonic collection to a DataGridView. As alternatives, I sometimes use the collections .ToTable() method to create a DataTable and then bind to that, or alternatively I manually bind using .AddRow()
Look at the documentation for IBindingList Interface in MSDN, it has a pretty good sample.
Create, for example, a CustomersList class in your model that uses a Customer class in your BLL. Bind the grid to an instance of the CustomersList class. The presentation layer has no knowledge of the subsonic table classes.
You probably need to use an Interface. You can easily create an interface based off of the Widget in your Dal(right click on the class and create an Interface from the class). Next take the Interface and add it to your Business Logic Layer or a seperate project just for interfaces. Once you have done that you can add a reference to the Interface both in the DAL and in the GUI. This can also help if you ever change your data storage from a Database to XML etc. etc.